BLM  LIBRARY 


I 


I 
I 
I 
I 
I 
I 
I 


88018873 


/      5T      \ 

FISH  &  WILDLIFE 
SERVICE 


US  Army  Corps 
of  Engineers 

Engineer  Topographic 
Laboratories 


Fourth 

National 

MOSS 

Users 

Workshop 

May  18  -  21,  1987 
Denver,  Colorado 


%-1 


BLMUBRARY  M^?? 

D^VcR  FEDERAL  CENJEn  ^'^^ 

P-_0.  BOX  25047  "^  C^^i^ 


DEWVER,  CO  80225-0047 

Proceedings 


Fourth  National  MOSS  Users 

Workshop 


Compiled  by 

U.S.  Department  of  the  Interior 

Bureau  of  Indian  Affairs 

Lakewood,  Colorado  80226 

July  1987 


I 


INTRODUCTION 


The  Fourth  National  MOSS  Users  Workshop  was  hosted  by  the  Bureau 
of  Indian  Affairs  and  Colorado  State  University  at  the  Stouffer 
Concourse  Hotel  in  Denver,  Colorado  on  May  18-21,  1987.   Over  125 
participants  attended  representing  Federal  and  state  agencies, 
universities,  and  the  private  sector. 

The  Map  Overlay  and  Statistical  System  is  approaching  a  turning 
point  in  its  development.   The  conversion  to  the  Prime  operating 
system  has  pointed  out  serious  deficiencies  in  the  software  code 
and  its  structure,  the  data  structure  itself,  and  the  user 
interface.   Dr.  Armando  Guevara,  team  leader  for  ESRI  in  the 
software  conversion,  provided  an  overview  of  many  of  these 
problems.   The  charge  to  the  attendees  was  clearly  to  evaluate 
MOSS  and  the  direction  its  development  is  to  take  in  light  of 
these  system  problems. 

Quite  clearly,  MOSS's  functionality  has  been  successfully 
demonstrated.   It  has  assisted  managers  in  making  resource 
management  and  land  use  decisions.   It  is  quite  capable  of 
producing  high  quality  cartographic  products.   Twenty-one  papers 
were  presented  detailing  software  development  and  system 
applications,  many  of  which  are  used  on  a  day  to  day  basis. 

The  evaluation  required  of  MOSS,  then,  is  not  whether  it  can  meet 
certain  functionalities,  but  whether  it  is  a  system  of  adequate 
sophistication  and  flexibility  to  meet  a  vast  majority  of  needs 
and,  if  not,  what  is  required  to  make  it  such  a  system. 

The  primary  topic  of  discussion  during  the  three  workshop 
sessions  also  centered  on  the  direction  MOSS  must  go  to  meet  user 
needs.   The  User's  Session  addressed  the  need  for  a  firm 
commitment  from  Management  to  support  and  develop  the  system. 
The  System's  Session  directly  attacked  shortcomings  in  the 
software  requiring  attention  on  a  long  and  short  term  basis.   The 
Manager's  Session  charged  the  Users  and  Systems  Groups  with 
providing  them  with  a  well  defined  package  of  needs  and 
suggestions . 

Over  the  course  of  the  next  several  months,  the  User,  System,  and 
Manager  groups  will  meet,  continuing  to  address  the  problems 
associated  with  bringing  MOSS  up  to  date  relative  to  GIS 
technology  as  a  whole. 

Herein  are  the  proceedings  of  the  technical  sessions,  including 
copies  of  each  presenter's  paper,  a  list  of  those  attending,  and 
a  summation  of  topics  of  discussion  from  the  group  sessions. 
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FOURTH  NATIONAL  MOSS  USERS  WORKSHOP 

SUMMARY  OF  MANAGEMENT  WORKGROUP  SESSION 

MAY  21 , 1987 


1  .0   INTRODUCTION 

This  document  presents  a  summary  of  the  results  of  the 
meeting  of  MOSS  MANAGERS  during  the  4th  National  Moss  Users 
Workshop.   The  papers  presented  at  the  workshop  clearly 
Indicated  that  the  MOSS  family  of  software  continues  to  be 
utilized  on  an  extensive  basis  by  the  GIS  community. 
However,  lack  of  software  support  and  development  emerged  as 
a  common  problem  among  all  users.   Reports  received  from  the 
Users  and  Systems  workgroups  confirmed  the  fact  that,  by  and 
large,  the  User  community  could  not  rely  upon  MOSS  being 
upgraded  or  maintained  properly.   Originally  developed  and 
supported  by  USFWS,  subsequently  supported  and  upgraded  by 
the  BLM,  MOSS  has  become  a  travelling  stepchild. 
Furthermore  these  agencies  have  never  received  proper  fiscal 
reimbursement  from  "Users"  to  help  defray  the  high  cost  of 
keeping  the  software  current.   In  short,  a  mechanism  has 
never  been  implemented  which  assigns  lead  responsibility  to 
an  agency  for  MOSS,  and  then  provides  through  interagency 
agreements  funding  from  the  user  agencies  to  the  responsible 
agency  to  defray  the  costs.   From  the  previous  3  workshops 
It  was  evident  that  getting  suggestions  for  software 
Improvement  and  criticisms  of  the  software  from  agencies  was 
easy.   The  rub  was  and  remains  whether  agencies  are  willing 
to  pay  for  what  they  want/get.   As  a  result,  it  was 
concluded  that  the  proper  action  for  the  management  team  to 
Initiate  was  to  create  a  Joint  team  of  users,  systems, and 
management  with  the  specific  assignment  to  first  scope  out 
the  requirement,  secondly  to  obtain  agency  concurrence 
through  funded  agreements,  and  finally  to  implement  the 
infra-structure  within  DO  1  . 


2.0   OBJECTIVE 

The  management  team  defined  Its  objective  as  follows: 

To  create  an  architecture  within  DO  I  which 
establishes  a  lead  MOSS  agency,  provides  for  financial 
support  to  the  agency,  and  insures  continued  and  long  term 
commitment  by  DO  I  agencies  to  the  architecture. 

In  order  to  accomplish  this  objective  an  action  plan  was 
developed.   This  plan  is  outlined  In  the  following  section, 


I 


3.0   ACTION  PLAN 

1.  Establish  a  MOSS  Configuration  Management  Team 
(MCMT)  of  user,  system,  and  management  personnel  to 
facilitate  the  development  and  Implementation  of  the  MOSS 
ACTION  PLAN.   In  addition,  the  MCMT  shall  also  continue  In 
existence  after  the  development  of  the  plan  to  oversee  the 
plans  implementation,  and  to  then  serve  as  the  oversight 
team  for  continued  operations.   Mr.  Claude  Chr I stensen  ( FWS ) 
and  Mr.  Bill  Bonner  (BIA)  were  appointed  to  serve  as  interim 
co-chairmen  for  the  MCMT. 

2.  Require  DO  I  agencies  to  assign  appropriate 
personnel  to  MCMT  to  participate  In  the  development  and 
implementation  of  the  architecture. 

3.  Develop  a  comprehensive  plan  which  is  adjudicated 
through  the  agencies,  and  then  approved  through  signature. 
This  plan  must  provide  funding,  system  standards,  personnel 
commitment,  and  data  standards. 

4.  Draft  charter  for  MCMT.   Utilize  existing 
cooperative  strategy  charter.   Mr.  Claude  Chr i stensen  of  FWS 
was  assigned  this  task. 

5.  Task  the  User  Workgroup  to  compile,  describe,  edit, 
and  prioritize  their  requirements.   This  tasking  carries 
forward  the  requirement  to  include/consider  all  previous 
Input  as  obtained  In  the  preceding  3  conferences.   Both 

management  and  systems  representatives  are  to  be  assigned  to 
this  task  with  the  User  having  the  lead  responsibility. 
This  latter  requirement  Is  Intended  to  Insure  vertical  and 
horizontal  communications. 

6.  Task  User  Workgroup  to  recommend  basic  or  core 
system  which  is  adjudicated  by  the  agencies. 

7.  Task  the  Systems  Workgroup  to  scope  the  short  term 
fixes  which  are  needed  for  MOSS.   Further  task  them  to  scope 
the  requirement  as  input  by  the  user  team  from  steps  5  and 
6.   Scoping  Is  to  Include  all  costs  (  le,  annual, 
operations,  start-up,  development,  etc.)  as  well  as, 

t Ime I  I nes . 

8.  Task  the  Systems  Workgroup  to  prepare  a 
software/system  development  plan  which  considers  Impacts  on 
users,  and  agencies. 

9.  Convene  the  MCMT  no  later  than  (NLT)  August  1987  to 
evaluate  the  Input  from  the  user  and  systems  workgroup 
tasks.   Determine  course  of  action,  prepare  detailed  MOSS 
Action  Plan,  and  report  back  to  user  and  system  workgroups. 


10.  Obtain  review  of  MOSS  Action  Plan  from  user  and 
system  workgroups  NLT  September  1987. 

11.  Present  MOSS  Action  Plan  to  Directorates  NLT 
October  1987.   This  presentation  shall  Include  executive 
summary,  required  resources  (funding  and  personnel), 
required  MOU  and  I  AGs,  coordination  with  O I RM ,  and 
coordination  with  I DCCC. 

12.  Obtain  approval  of  Directorate  and  Implement  plan. 
This  action  shall  Include  the  requirement  for  each  agency 
representative  to  secure  the  transfer  of  appropriate  funding 
to  the  designated  lead  agency,  and  the  authorization  for 
their  own  staffing  requirements.   In  addition,  the  MCMT 
shall  be  prepared  to  assist  the  lead  agency  In  Implementing 
any  contractual  requirements  which  are  necessary  for  the 
success  of  the  MOSS  Action  Plan. 

13.  In  role  as  the  oversight  committee,  the  MCMT  shall 
monitor  the  progress  of  the  implementation  of  the  plan  and 
regularly  report  bacl<  to  the  system  and  user  workgroups,  as 
well  as  OiRM  and  the  t DCCC,  on  progress.   The  MCMT  shall 
meet  quarterly  to  insure  that  the  MOSS  Action  Plan  Is 
accomp I  i  shed . 


4th  MOSS  USERS  WORKSHOP 

DENVER,  COLORADO 

MAY  18-21 ,  1987 

RECOMMENDATIONS  FROM  SYSTEMS  WORKGROUP  DISCUSSIONS 

INTRODUCTION 

MOSS  has  Significant  problems  which  make  It  difficult  to  maintain 
and  enhance.  For  this  reason,  attempting  to  address  particular 
problems  with  particular  commands  often  leads  to  less  than 
perfect  solutions.  It  Is  Important  to  Improve  MOSS  by  addressing 
its  most  fundamental  problems  which  are  I  Imlting  Its  rel  I  ab i  I  ity, 
performance  and  maintainability.  As  MOSS  moves  to  more  computer 
architectures  such  problems  become  greater.  We  have  reached  the 
point  where  continued  support  and  development  of  MOSS  will  become 
virtually  Impossible  without  some  changes  to  both  MOSS  and  MOSS 
maintenance  procedures. 

MOSS  has  arrived  at  a  turning  point  In  its  evolution.  The  recent 
porting  of  MOSS  to  the  Prime  environment  has  pointed  out  some 
specific  areas  of  machine  dependencies  and  general  problems  in 
the  code.  Some  of  these  problems  have  been  addressed  as  part  of 
the  conversion.  Others  are  being  dealt  with.  Still  others  remain 
to  be  addressed.  The  Systems  Group  has  discussed  MOSS  and  what  is 
required,  based  upon  our  experience  and  newly  available 
information  from  the  conversion,  to  assure  a  future  for  MOSS 
while  avoiding  a  complete  rewrite  and  using  as  much  as  possible 
of  ex  I st I ng  code . 

OBJECTIVES 

The  major  objectives  of  the  work  we  feel  Is  necessary  are  as 
f o I  I ows : 

Improve  the  reliability  and  performance  of  the  software. 

improve  the  maintainability  of  the  software. 

Focus  on  the  Prime  environment  but  develop  a  set  of  code  which  is 
supportable  on  multiple  architectures.  This  will  address  the 
question  of  support  on  many  computers  (Prime,  Data  General,  Vax , 
PC,  plus  others  in  the  future). 

Accomplish  some  ground  work  which  will  provide  for  a  more 
promising  future  for  MOSS. 

MOSS  REQUIREMENTS 

The  following  tasks  could  be  accomplished  In  the  short  to  medium 
term  and  go  far  toward  accomplishing  the  above  objectives.  Users 
and  managers  must  realize  that  not  all  of  these  tasks  will  result 


I 


I 


in  immediate  returns  to  the  user  community  but  wiii  significantly 
improve  tine  maintainability  of  the  code  and  make  responsive 
software  maintenance  more  realistic. 

For  the  nearly  one  half  million  lines  of  code  in  IMOSS  and  family 
the  following  should  be  done  (In  order  of  priority)  as  part  of  or 
after  the  Prime  version  release. 

Define  COMMON  blocks  consistently. 

Go  to  32  bit  coordinate  storage.  (Short  Term,  Improve 
Performance)  * 

Isolate/Consolidate  I/O,  Graphics,  Parsing,  Prompting,  Error 
Processing.  * 

Implement  I/O  channel  manager  with  strict  Read/Write  privileges 
on  file  OPEN. 

Minimize  use  of  Command  Languages  and  Operating  System  specific 
directory,  ACL,   and  searchllst  features. 

Change  Disk  Arrays  to  utilize  Virtual  Memory.  * 

Remove  duplicate  data  from  data  files   (POLYGON. DH,   POINT. DT, 

MASTER. DH) 

Implement  other  code  changes  as  recommended  by  ESR I . 

Develop,  implement  and  enforce  a  strict  DO  I -w I de  procedure  for 
check  out,  modification,  and  distribution.  Libraries  for  tasks 
such  as  I/O,  Graphics,  Parsing,  Prompting,  and  Error  Processing 
should  be  developed  and  distributed  to  software  developers  only 
as  link  modules  so  that  strict  controls  can  be  kept  on  low-level 
source  code  modification.  Users  should  be  made  aware  of  problems 
associated  with  making  local  modifications.  The  government  should 
strive  toward  making  a  single  government  employee  responsible  for 
a  single  program  (MOSS,  MAPS,  ADS,  AMS ,  COS,  etc.)  to  keep  the 
management  of  software  development  realistic.  Funding  should  be  a 
priority  for  these  positions  so  that  continuity  is  maintained. 
This  person  should  be  a  technically  involved  staff  member. 

NOTE:  Those  items  footnoted  with  a  *  will  result  in  immediate 
returns  to  the  user  in  reliability,  consistency,  or  performance 
of  the  software. 

IMMEDIATE  ACTION  ITEM 

A  very  rough  estimate  of  what  will  be  required  to  accomp  i  i  sh 
these  tasks  Is  4-5  high  level  programmers  for  4-5  months. 
However,  we  strongly  suggest  that  each  agency  contribute  a  single 
technical  person  for  ten  hours  per  week  during  June.  These  people 
will  further  develop  these  requirements  and  develop  costs 
estimates  for  each  item  so  that  Information  will  be  available  by 
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July  1  for  budgeting  purposes.  Some  of  these  tasks  which  are 
already  funded  by  BLM  must  be  Identified.  Based  upon  this  work, 
agencies  will,  for  the  first  time,  have  detailed  Information 
about  the  cost  of  correcting  these  problems  with  MOSS. 

FUTURE  MOSS  DEVELOPMENTS 

The  above  tasks  will  prepare  for  the  accomplishment  of  several 
long  term  tasks  which  would  be  desirable  future  developments  for 
MOSS.  However,  even  without  the  accomplishment  of  the  long  term 
tasks,  we  feel  the  short  term  tasks  will  significantly  Improve 
the  reliability,  performance,  maintainability  and  suppor tab i  I  I ty 
of  MOSS. 

The  long  term  tasks  are: 

Move  toward  graphics  standards  (GKS  ?). 

Develop,  Implement  and  enforce  DO  I  coding  standards. 

Implement  an  Arc-Node  data  structure. 

Implement  an  RDBMS . 

TIME  FRAMES 

The  following  major  categories  were  discussed. 

Short  term:  the  Prime  version  release. 

Med  I  urn  term:  any  remaining  I  terns  from  the  eight  listed  by  the 
Systems  Group  plus  fixes  Identified  by  the  User  Group. 

Long  term:  RDBMS,  Arc-Node  data  structure,  graphics  standards, 
coding  standards,  etc. 
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FOURTH  NATIONAL  MOSS  USERS  WORKSHOP 

Summary  of  Users  Workgroup  Session 
May  20-21,  1987 


I.  SPECIFIC  COMMENTS  BY  AGENCY  USERS 
1.  Bureau  of  Land  Management  (BLM) 


The  recent  merger  between  Automated  Land  and  Minerals  Record  System  (ALMRS) 
and  GIS  has  resulted  in  an  emphasis  on  ALMRS  and  a  shift  in  programmers  to 
ALMRS. 

Regarding  MOSS  software,  there  are  still  the  old  problems  that  need  to  be 
fixed;  new  and  different  problems  with  the  BLM  87.01  version;  and  less  people 
available  to  fix  them.  While  several  problems  have  been  addressed,  and  two 
persons  are  being  assigned  to  work  on  MOSS  (George  Fuller  and  Bill  Turner, 
Autometric,  Inc),  there  are  not  sufficient  terminals  available. 

There  is  a  formal  mechanism  and  procedures  to  get  fixes/releases  out  to  other 
users,  but  no  one  person  is  currently  designated  to  handle  this  task. 

Support  for  MOSS  on  the  Data  General  minicomputers  may  be  phased  out  at  the 
BLM-Denver  Service  Center  (DSC)  unless  major  problems  at  the  BLM-Colorado 
State  Office  require  support  from  the  DSC. 

Summary:  BLM  needs  more  people  and  equipment  to  do  the  job  of  fixing  daily 
problems;  providing  telephone  support  for  the  field  personnel;  testing  the 
software  on  the  Prime;  and  coordinating  release  versions,  etc. 

Current  Plan:  The  effort  to  support  and  test  MOSS  on  the  Prime  will  begin 
next  week,  with  an  initial  release  expected  in  July  1987.  Work  will  continue 
through  the  Fall,  with  a  final  release  in  late  FY87  or  early  FY88. 

2.  U.S.  Forest  Service  (USES) 

Nicolet  National  Forest,  WI: 

The  Forest  Service  currently  has  a  subscription  service  with  Autometric,  Inc. 
for  support  and  software  releases  and  are  satisfied  with  the  level  of  support 
provided  to  date.  The  Rhinelander,  WI  office  already  has  the  4100  and  4200 
Tektronix  software  enhancements  on  its  DG  computer. 

USES,  Region  8,  Atlanta,  GA: 

The  Region  8  Office  currently  has  no  inhouse  software  support  or  subscription 
service  and  relies  on  the  FWS  National  Ecology  Center  (NEC)  and  BLM-DSC  for 
telephone  support  when  needed.  Its  short  term  plans  are  to  continue  to  rely 
on  FWS  and  BLM  for  support  on  the  DG;  if  support  becomes  unavailable  in  the 
future,  they  may  have  to  look  at  using  other  systems  to  accomplish  their  work. 


3.  Department  of  Energy  (DOE) 

Los  Alamos  National  Laboratory,  NM: 

The  Los  Alamos  National  Laboratory  currently  has  a  subscription  service  with 
Autometric,  Inc.,  and  is  pleased  with  the  support  provided  to  date.  No 
inhouse  support  capability  is  planned  for  the  future.  Although  MOSS  will 
continue  to  be  used  on  the  DG,  and  funding  for  several  fixes  to  the  DG  version 
was  planned,  there  is  no  longer  sufficient  justification  due  to  internal 
decisions  and  plans  to  use  Delta-Map  software. 

4.  Bureau  of  Indian  Affairs  (BIA) 

The  BIA  is  using  the  BLM-DSC  Hotline  service  for  MOSS  support  and  FWS-NEC  for 
AMS  support.   Inhouse  support  is  planned  for  MOSS  on  the  Prime  and  the  BLM 
Hotline  service  will  continue  to  be  a  source  of  daily  support  to  BIA  users. 

5.  U.S.  Fish  and  Wildlife  Service  (FWS) 
National  Ecology  Center  (NEC),  Ft.  Collins,  CO: 

The  FWS-NEC  currently  has  inhouse  support  for  AMS  and  provides  outside  support 
to  several  agencies.  There  is  virtually  no  support  for  MOSS  or  COS  software 
on  the  DG  or  Prime,  and  none  is  planned  for  the  future.  Limited  testing  of 
AMS  on  the  Prime  is  being  conducted  at  the  NEC,  but  responsibility  for  formal 
testing  and  release  of  AMS  for  the  Prime  is  with  the  FWS  National  Wetlands 
Inventory  Center  (NWIC),  St.  Petersburg,  Florida. 

National  Wetlands  Research  Center  (NWRC),  Slidell,  LA: 

The  FWS-NWRC  currently  has  limited  inhouse  AMS/MOSS/COS  support  for  both  the 
DG  and  Prime  computers;  however,  there  is  not  sufficient  personnel  to  maintain 
support  for  both  computers.  Software  support  is  currently  provided  to  several 
outside  users. 

FWS  Region  5,  Annapolis  Field  Office: 

The  FWS  Annapolis  Field  Office  currently  has  a  subscription  service  with 
Autometric,  Inc.,  and  is  running  AUTOGIS  on  a  VAX  computer  as  the  first  BETA 
test  site.  The  AMS  is  also  being  used  for  inhouse  digitizing  tasks. 

6.  State  of  Louisiana,  Department  of  Natural  Resources  (DNR). 

The  Louisiana  DNR  currently  has  a  subscription  service  with  Autometric,  Inc., 
but  depend  on  the  FWS-NWRC  for  most  of  their  support. 

II.  USER  WORKGROUP  CONCERNS/CONCENSUS 

1.  MOSS  Software. 

°   Funding  must  be  available  to  get  MOSS  working  on  the  Prime,  at  least 

to  the  level  that  it's  working  on  the  DG's.  This  should  occur  since  BLM 

is  authorizing  FY87  funding  for  contract  personnel  support.  ^ 


I 


I 


1°   Funding  must  become  available  to  get  the  fundamental  problems  identified 
by  ESRI  fixed,  to  make  MOSS  a  better  system,  provided  that  the  old 
problems  identified  in  previous  years  are  also  fixed  in  the  Prime  version 
(e.g.,  build  an  arc/node  structure).  If  these  are  not  addressed,  it  may 
not  be  worth  sinking  additional  funds  into  MOSS.  There  must  be  a 
commitment  by  management  for  a  "modern"  GIS. 

2.  MOSS  Support 


I 


I 

There  is  currently  no  coordinated  effort  in  any  agency  to  provide  GIS  support 

I       Each  agency  is  getting  by,  using  whatever  means  or  methods  necessary  to  get 
its  job  done.  This  makes  it  impossible  to  achieve  interagency  or 
Department-wide  coordination  for  GIS  support. 

I  "   The  current  lack  of  systems  support  in  each  agency  will  most  likely 

continue,  making  the  initial  goal  of  centralized  GIS  support  within  DOI 
virtually  impossible.  Either  we  go  on  "status-quo"  or  initiate  an 

II  effort  to  obtain  centralized  support  via  a  DOI-wide  procurement.  The 
■  Department  is  currently  investigating  the  possibility  of  a  DOI 

Digitizing  Services  Contract  and  there  is  talk  of  a  DOI  procurement  for 
a  second  GIS.  Why  not  include  GIS  support  as  well?  This  would  force 
agencies  to  commit  funding  for  software  support.  If  they  cannot,  then 
they  are  on  their  own;  we  cannot  continue  to  expect  one  or  two  agencies 
to  support  all  DOI  agency  users,  as  well  as  users  in  other 
Departments.  This  places  an  unfair  burden  on  these  agencies, 
which  essentially  donate  personnel  time  and  computer  resources  for  GIS 
support  without  cost  reimbursement. 
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The  current  transition  from  DG  to  Prime  will  require  more  systems  support, 
not  less.  MOSS  is  now  running  on  DG,  Prime,  VAX  and  PC  computers. 
The  Government  must  commit  to  GIS  software  research  and  development; 
user  support;  system  maintenance;  documentation;  and  upgrades. 

°       Support  must  be  maintained  for  the  DG  versions  of  MOSS,  at  least  for  the 
next  few  years. 

3.  Agency  Coordination  on  Software  Status  and  Development  Needs 

°   There  is  currently  no  focal  point  in  any  agency  for  assistance  in 

obtaining  current  GIS  software  releases  and/or  documentation.  A  person 
from  each  agency  should  be  designated  to  coordinate  requests  for 
software  and  subsequent  distribution.  This  should  lead  to  unified 
versions,  at  least  within  each  agency  and  hopefully  throughout  DOI. 


o 


There  is  currently  no  formal  mechanism  for  obtaining  information  on  the 
GIS  software  status.  An  agency  bulletin  board  on  a  dedicated  micro  or 
use  of  COMPUSERVE  would  be  useful  to  GIS  programmers  and  users  for 
reporting  problems,  documenting  fixes,  reporting  on  software  status,  etc. 

A  MOSS  Users  Group  must  be  created  in  order  to  provide  input  on  MOSS 
problems,  development  needs,  etc.,  to  Washington  Office  Management  staff. 

A  procedure  to  allow  users  ready  access  to  data  captured  by  other  agencies 
must  be  established. 
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1.-  Introduction 

The  objective  of  this  software  conversion  effort  was  to  convert  the 
various  geoprocessing  software  programs,  i.e.  MOSS,  WAMS ,  AMS,  MAPS, 
COS,  C0S3,  PROJECTION,  REFORM  and  PENPLOT,  from  the  Data  General 
computer  to  the  PRIME  computer.  The  PRIME  implementation  was  required 
to  run  as  well  as  the  Data  General. 

This  effort  did  not  require  that  the  software  be  enhanced,  nor  that 
problems  in  execution  on  the  Data  General  be  cured  in  the  process  of 
conversion  on  the  PRIME. 

In  order  to  meet  the  objectives  of  the  conversion  effort,  it  was 
necessary  to  establish  a  cycle  of  test  requirements  to  measure  the 
success  of  the  conversion. 

Six  months  was  the  time  frame  to  do  the  conversion. 


2.-  Conceptual  Overview 

The  basic  strategy  in  accomplishing  the  conversion  was  to  install 
government's  software  on  the  Data  General  computer  at  the  Environmental 
Systems  Research  Institute  (ESRI)  in  Redlands  California.  The 
resulting  installation  established  the  "baseline"  conditions  for 
software  execution  and  performance  (and  for  acceptance  and  testing  by 
the  government)  against  which  the  converted  code  on  the  PRIME  were  to 
be  tested  and  compared. 

The  conversion  process  would  then  consist  in  making  one-to-one 
substitutions  between  software  concepts  and  constructs  on  the  Data 
General  and  corresponding  concepts  and  constructs  on  the  PRIME. 

The  substitutions  would  be  defined  by  a  growing  set  of  rules  which  were 
expected  to  drive  the  conversion  process  itself.  In  this  sense,  the 
conversion  process  would  chiefly  consist  of  discovering  what  these 
rules  were,  documenting  them,  and  then  applying  them  to  the  Data 
General  code  versions  in  order  to  create  new  PRIME  code. 

Thus  the  conversion  process  was  not  only  going  to  produce  new  source 
code  but  also  this  set  of  rules  which,  embodied  in  PRIME'S  CPL  and 
FORTRAN  programs,  would  create  a  software  tool  to  assist  in  the  actual 
conversion  process.  In  this  sense  the  conversion  was  to  be  "rule 
based"  and  supported  by  command  language  procedures  (CPL)  which  would 
filter  source  code  by  applying  the  rules  to  it. 

The  success  of  the  conversion  was  to  be  measured  by  (1)  successfully 
compiling  and  binding  (linking)  the  converted  code  and  then  (2) 
executing  the  code  as  to  meet  the  government's  defined  test  and 
acceptance  criteria. 
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2.1.-  Approach  to  Accomplishing  the  Objectives 

ESRI's  initial  approach  to  accomplishing  the  objectives  of  the  software 
conversion  involved  the  following  principles: 

a)  Placing  the  effort  in  the  hands  of  ESRI's  most  qualified  software 
programming  and  software  support  staff,  combined  with  staff 
augmentation  especially  for  this  project. 

b)  Analyzing  of  the  overall  structure  of  the  software  and  its  file 
structures  prior  to  deciding  how  to  proceed  with  the  software 
conversion  effort. 

c)  Establishing  a  growing  set  of  rules  to  govern  the  conversion,  so 
that  conversion  would  be  increasingly  automated  as  the  project 
progresses . 

d)  Using  a  designated  software  librarian  and  test/acceptance  sets  to 
maintain  control  of  the  conversion  process. 

e)  Nominating  a  single  project  manager  in  overall  control  of  all 
aspects  of  the  conversion,  with  most  capable  and  experience  staff 
assigned  to  MOSS,  with  other  staff  assigned  to  more  recent  and  better 
documented  software. 

f)  Implementing  constant  information  flow  between  working  groups  to 
insure  that  new,  valid  conversion  rules  were  adopted  as  quickly  as 
possible. 

g)  Testing  converted  code  incrementally  to  insure  that  each  progressive 
step  is  succesful  before  proceeding. 

h)  Limiting  the  conversion  to  the  absolute  minimum  code  changes  to 
maintain  current  documentation  as  much  as  possible  and  avoid 
introducing  new  problems  into  the  software  systems. 


2.2.-  Summary  of  Plan 
The  following  basic  steps  outline  the  conversion  plan: 

1.  Obtain  the  Data  General  version  of  the  software  and  install  it  on 
ESRI's  Data  General  machine.  This  was  to  provide  the  "baseline"  for 
comparing  with  the  converted  software  on  the  PRIME  computer. 

2.  Obtain  the  set  of  acceptance  test  procedures  from  the  government 
and  run  these  on  the  Data  General  version  of  the  software  to  insure 
that  the  software  on  the  Data  General  can  meet  the  acceptance  tests, 
and  to  define  the  "baseline"  in  terms  of  acceptance. 

3.  Determine  the  initial  correspondence  between  the  Data  General  code 
and  PRIME   code   regarding   file   structures,   subroutine  libraries  and 


I 
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software  organizational  concepts. 

4.  Based  on  these  initial  correspondences,  and  the  identified 
structure  of  the  software,  divide  the  code  into  discrete  packages  and 
assign  these  to  the  programmers. 

5.  Based  on  the  initial  correspondences,  begin  the  creation  of  a  set 
of  rules  to  guide  the  actual  code  conversion  process. 

6.  Generally  working  in  parallel,  for  each  individual  "package"  of 
code: 

a)  Load  the  package  on  the  PRIME; 

b)  Compile  with  FORTRAN  77; 

c)  Substitute  code  until  compile  problems  are  solved; 

d)  Load  and  execute  the  PRIME  code  until  the  acceptance 
test  criteria  are  met. 


7.   Deliver  PRIME  version  (FORTRAN  77)  of  software  source  code. 

2.3.-  The  reality  of  time 

At  the  time  of  assuming  responsibility  for  the  conversion  effort  a  full 
concensus  on  the  rule  layout  for  the  manual  conversion  of  the  software 
had  not  been  reached.  This  affected  the  conversion  of  functions  not 
handled  by  the  automated  tools.  This  included  aspects  of  multitasking, 
DG  linkage  environment,  PUSH/POP  at  OS  level  and  internal  octal 
handling  (characters,  constants).  The  first  re-scheduling  step  was  to 
design  these  functions  so  they  could  be  appropriately  emulated  on  the 
PRIME. 

After  three  months  of  ongoing  conversion  efforts  most  of  the  code  had 
been  compiled  and  links  were  being  completed  and  verified.  For 
programs  that  could  be  executed  we  found  they  did  not  work  because  the 
code  could  not  be  made  operational  "as  is".  Mixture  of  types  was  a 
serious  problem  in  FORTRAN  77  (octal  and  decimal  equivalent  comparisons 
were  failing);  file  handling  was  not  documented  for  some  programs 
(some  files  on  the  base  line  system  were  constructed  several  years  ago, 
yet  were  used  by  programs).  The  assumption  that  the  code  could  be 
converted  without  understanding  what  it  did  did  not  hold  up;  code  had 
to  be  inspected  and  understood  in  many  cases. 

The  automated  conversion  tools  took  care  of  the  bulk  of  the  conversion. 
However,  in  several  instances  it  was  necessary  to  inspect  the  code  for 
FORTRAN  machine  incompatibilities  that  could  not  be  detected  until 
run- time. 

The  fact  that  a  program  compiled  and  bound  was  no  gurantee  that  It 
would  execute   properly   (per   DG) .    Part  of  the  main  complication  was 
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that  the  MOSS  family  of  programs  was  based  on  a  integer  short 
architecture,  fortran  66  (not  the  standard  version),  fortran  5  (D.G. 
version)  and  a  potpourri  of  fortran  77. 

Added  to  the  above,  it  had  a  lack  of  consistency  in  communications 
protocol,  an  inconsistent  and  unorthodox  mixture  of  data  types,  and 
duplication  of  functions  at  the  software  data  base  level. 

Based  on  the  experience  of  converting  a  well  defined  system  like 
ARC /INFO  from  the  PRIME  to  the  VAX  environment  (with  less  than  150,000 
lines  of  code),  I  immediately  realized  that  the  time  estimates  needed 
to  be  re-evaluated  for  this  conversion. 

As  a  simple  academic  exercise  I  looked  at  the  MOSS  program  first.  The 
MOSS  subsystem  had  89  programs  and  94A22  lines  of  code  (701  routines). 
Producing  a  program  a  day  (which  is  not  realistic)  would  give  a 
delivery  date  of  May  31,  1986. 

Since  I  had  found  that  parts  of  the  conversion  could  not  be  done 
without  actually  modifying  the  code  (which  is  like  writing  new  code), 
and  if  we  added  to  this  the  lack  of  knowledge  in  some  of  the  areas  of 
file  structure  and  communications  protocol  used  in  the  MOSS  family  of 
programs  (thus  having  the  task  of  deciphering  black  boxes),  I  found  the 
time  table  leading  to  16  hour/days  for  the  next  5  months. 

I  wanted  to  think  that  we  could  produce  a  production  curve  of  this 
type: 


454,288  I  * 

I  * 

Lines     I  * 

of       I  * 

Code      I  * 

I  * 

X*********** 


TIME 


yet  I  had  strong  doubts  after  inspecting   the  code  that  this  was 
possible. 
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2.3.1.-  Project  Plan  Revisited 
At  the  time  the  tasks  were  distributed  in  the  following  way: 

Team  Member      Sub-system      Lines  of  Code   Executables  CLI 


ADDWAMS 

2454 

1 

0 

AMS 

95321 

80 

476 

COLOR 

1622 

3 

0 

COS 

16937 

14 

35 

MAPS 

37928 

21 

2 

PENPLOT 

5518 

1 

0 

REFORM 

15071 

22 

22 

START 

1735 

0 

1 

UTILITY 

6840 

0 

0 

BYTE 

972 

0 

0 

ADS 

45024 

50 

217 

COS  3 

35296 

2 

5 

GKS 

10785 

4 

3 

PLOTLIB 

3119 

0 

0 

PROJ 

11784 

1 

1 

PROJ.NWI 

9046 

1 

1 

SET 

2832 

0 

0 

TEKLIB 

4372 

0 

0 

TEKTRONIX 

2163 

0 

0 

ZETA 

1729 

0 

0 

BLMZETALIB 

4638 

0 

0 

CALCOMP 

1672 

0 

0 

GERBER 

168 

0 

0 

HEWPACK 

3499 

0 

0 

MOSS 


93052 


89 


TOTAL:  289  programs    766  CLI 

(441,962  lines)      (12,326  lines) 


The  basic  tally  of  programs  was  289  FORTRAN  and  766  CLI.  Average 
number  of  lines  per  FORTRAN  program  was  of  1529.28  and  for  CLI  was 
16.09.  Based  on  a  four  person  team  there  was  an  average  of  72.25 
programs/person  and  191.5  clis/person.  Based  on  an  8  hour  day,  4  week 
month  (not  counting  week-ends),  the  following  chart  expresses  the  time 
table  for  the  conversion  of  one  program-per-day/1529  lines  of 
code-per-day : 
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SCHEDULE  I 


!========>  (third  week  of  april) 

I 

-J— F~M— A— M— J— J— A— S— 0— N— D— J— F— M— A 
1987  1988 


To  commit  to  this  schedule  it  was  necessary  to  have  every  day  a  program 
compiled,  linked  and  running.  Given  the  status  of  the  code  (that  it 
required  manual  fixing  and  re-writing)  I  found  this  schedule 
unrealistic. 

Estimating  a  program  every  two  days  (765  lines  of  code-per-day)  the 
chart  looks  like  this 


SCHEDULE  II 


I====================>  (first  week  of  August) 

I 

-J— F~M— A— M— J—J— A~S— 0~N— D~J— F~M--A 
1987  1988 


I  felt   this  was   a  feasible  schedule  if  the  conversion  curve  went  as 
outlined  above. 

Finally,  a  schedule  of  a  program  every  three  days   (510  lines  of 
depured-code-a-day)  looks  like  this: 


SCHEDULE  III 

(first  week  of  November) 
1========================^ ===> 

I 

-J— F— M— A— M— J— J— A— S— 0— N— D— J~F— M— A 


1987  1988 

As  can  be  noted,  none  of  this  schedules,  although  realistic,  met  the 
contractual  delivery  date  of  April  3,  1987. 

The  next  approach  was  to  reduce  the  conversion  load  per  conversion  team 
member  by  adding  three  additional  experienced  senior  programmers  to 
support : 

a)  All  CLI  ~>  CPL  conversion. 

b)  Testing  of  low-levels  on  PRIME. 
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c)  Support  ADS  conversion-capture  phase. 

d)  Support  AMS  conversion-digitizing  and  data  base 
functions. 

e)  Support  COS,  C0S3  and  GKS 


2.3.2.-  What  to  do 

Unforseen  factors  were  delaying  the  MOSS  Conversion  Project.  I  found 
that  with  current  trends  the  project  would  not  be  completed  by  April  3, 
1987.   There  were  two  major  issues: 

a)  The  need  to  do  functional  replacement  of  code 
by  having  to  re-write  a  given  routine.  This 
required  understanding  what  the  routine  does. 

b)  The  amount  of  code  required  to  be  converted. 
The  above  issues  could  be  resolved  by: 


a)  Extending  the  delivery  date  to  second  week  of 
August  1987 

Or 


a)  Add  three  senior  programmmers . 


The  latter  solution  was  chosen.  It  was  necessary  however  to  get  prompt 
action  from  the  government  whenever  documentation  was  required  on  file 
structures.  Conversion  could  not  proceed  if  system  files  had  no 
documentation  (how  they  were  created,  what  they  contain,  how  they  are 
used  and  what  programs  use  them).  Time  scheduled  could  not  be 
maintained  if  the  conversion  had  to  be  stopped  to  determine  what  a 
given  piece  of   software  does  or  the  identity  use  of  a  file  structure. 

For  the  purpose  of  driving  the  conversion  process,  a  series  of  calling 
chart  schemas  were  assembled.  These  calling  charts,  had  all  the  MOSS 
family  of  software  categorized  by  function,  program(s)  used  and  routine 
calling  sequence. 

Specific  task  development  was  then  guided  by  the  calling  charts  put 
together.  The  basic  strategy  was  to  first  have  the  "frame"  of  each 
subsystem  installed  and  running  on  the  PRIME  install  directory. 
Incrementally,  the  "frame"  would  be  delivered  with  new  functionality. 
The  increment  was  guided  by  three  criteria: 

a)  Communication  and  data  transfer  needs.  The  CAPTURE  function 
of  ADS,  the  IMPORT  function  of  MAPS  and  the  IMPORT  function 
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of  MOSS  were  the  first  installed. 

b)  Logical/Lexicagraphical  order.  Since  there  was  no  clear 
"system"  division  in  MOSS  in  general,  conversion 
proceeded  following  the  calling  chart  handbook  on  a  program 
basis . 

c)  The  above  two  criteria  would  be  overwritten  if  system 
documentation  was  hindering  the  conversion  process. 


All  the  issues  of  mapping  CLI  functions  into  CPL  had  to  be  accomplished 
prior  to  any  further  software  modifications.   These  included: 

a)  PUSH/POP 

b)  Environments  (DIRECTORY,  SEARCHJLISTS) 

c)  Linkages.  Linkage  resolving. 

d)  List  searching 

The  CLI  conversion  was   to  proceed  on  a   top-down/bottom-up  fashion 
following  the  frame  schema  whenever  possible. 


3.-  The  software  strikes  back 

Once  having  completed  the  software  conversion  and  passed  the 
governments  quality  assurance  tests,  several  important  facts  about  the 
MOSS  family  of  programs  have  come  to  light.  They  will  be  useful  in 
handling  the  potential  problems  that  will  come  up  with  it's  use  under 
FORTRAN  77. 

It  goes  without  saying  that  there  is  a  profound  dimension  to  the  design 
of  software  systems.  Designing  not  only  affects  the  overall 
architecture,  maintenance  and  efficiency  of  a  software  system,  but  it 
also  greatly  affects  it's  reliability.  There  are  several  aspects  in 
the  designing  of  a  software  system  that  one  has  to  cover:  functional 
design,  architectural  integrity  design  and  efficiency  design.  These 
three  types  of  design  are  mutually  exclusive  in  many  ways  and  one  has 
to  carefully  blend  the  three  to  allow  the  design  goals  of 
functionality,  integrity  and  efficiency  to  meet. 

Designing  for  architectural  integrity  and  efficiency  requires  a 
concentration  on  the  important  aspects  of  the  problem,  so  as  to  avoid 
redundant  computations  and  to  design  data  structures  that  exactly 
represent  the  information  needed  to  solve  the  problem.  If  the  design 
is  successful,  the  result  is  not  only  an  efficient,  reliable  and 
architecturally  sound  system,  but  a  collection  of  tools  and  methods 
that  will  allow  the  graceful  expansion  growth  of  the  system. 

Geographic  information  systems  are  technologically  complex  systems.  It 
has  not  been  until  recently  that  software  engineering  design  techniques 
have  been  applied  to  the  design  and  implementation  of  CIS.  United  with 
the  advent  of  computational  geometry,  computational  topology, 
modular/structured  programming,   and   compiler  enforced  ANSI  standards. 
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the  development  of  CIS  software  becomes  more  robust  when  it  follows  the 
proper  engineering  guidelines. 


3.1.-  Conversion  Issues 

There  are  several  issues  that  come  up  when  converting  an  old  software 
system  like  the  MOSS  family  of  programs.  The  MOSS  family  of  programs 
may  have  had  a  initial  functional  design.  However,  there  is  no 
evidence  that  it  went  thorugh  a  design  cycle  where  integrity  and 
efficiency  were  considered.  There  is  a  strong  indication  that  the 
system  grew  with  no  design  guidelines.  By  not  having  these  guidelines 
the  system, having  been  developed  by  persons  with  different  backgrounds, 
expanded  in  a  very  haphazard  way. 

The  initial  implementation  of  MOSS  in  general  goes  back  as   early  as 

1977.   This   makes   the   system   a   technology   10  years  old  that  never 

caught  up  with  present  methods   and   techniques.   Ten  years   in   the 

computer  field  has  brought  us  the  S130  Eclipse  in  the  size  of  a  hand 
held  calculator. 

The  hardware  architecture  and  software  system  support  on  which  the  MOSS 
system  "grew"  allowed  for  many  violations  of  architectural  integrity  of 
which  the  user  would  never  be  notified.  Aside  from  checking  file 
status  I/O,  one  can  say  that  there  is  almost  no  formal  assertions 
imbedded  in  the  code  about  it's  behaviour.  The  developers  of  the  code 
in  general  did  not  consider  how  the  algorithms  could  fail. 

The  result  of  migrating  MOSS  to  a  newer  hardware  environment  with 
enforced  ANSI  standards  and  operating  systems  on  the  look  out  for 
"memory  corrupters"  or  "violators  of  restricted  areas"  is  that  we  have 
been  able  to  shed  light  on  future  potential  problems  that  may  come  up 
and  will  need  to  be  addressed. 

In  the  MOSS  software  conversion  we  can  differentiate  the  phase  of 
converting  the  software  so  it  executes  like  it  did  on  the  old 
hardware/software  architecture  environment  and  the  phase  that 
"corrects"  violations  that  appear  in  the  new  hardware/software 
architecture  environment.  The  "corrections"  were  not  to  make  the 
algorithms  any  better  but  were  to  emulate  the  behaviour  of  the  software 
from  the  old  architecture  to  the  new  architecture.  Despite  that  the 
process  has  left  the  algorithms  in  the  same  state,  it  has  been  useful 
to  identify  the  reasons  behind  it's  erratic  behaviour.  This  has  opened 
a  previously  undisclosed  matter  by  those  who  maintained  the  family  of 
programs.   The  following  cases  illustrate  some  of  the  problems. 


Case  1 

Processes  like  BUFFER  and  OVERLAY  which   "sometimes   work"  and   other 

times  produce   unuseable   results  is  caused  by  the  divide  by  zero.   The 

following  test  executed  on  an  MV4000  with  AOS/VS  and  FORTRAN  5   ignores 
divide  by  zero: 
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/ 


****  AOS/VS  Rev  7.54.00.00  /  Batch  Output  File  **** 

AOS/VS  CLI   Rev  07.54.00.00   18-MAR-87   12:32:43 

)  SEARCHLIST  : MACROS, :UTIL, : LANG: TCS 

)  DIRECTORY  :UDD:  ABDHUL:TEST 

)  DEFACL  ABDHUL,OWARE,+,RE 

) 

) 

)  TYPE  DZ.FR 

C 

C  . .  Program  to  test  divide  by  zero  condition 

C 

lANS  =3/0 

TYPE  '■IANS=",IANS 

END 

)  X  DZ 

IANS=       3 

) 

End  of  file 

AOS/VS  CLI   Terminating  18-MAR-8712:32:45 


The  same  test  executed  under  FORTRAN  77  on  the  DG  was  not  acceptable 
and  the  program  halted  with  the  message  "Fixed  point  overflow...  ERROR 
71174". 

This  problem  is  algorithmic  in  nature.  The  piece  of  code  that  has  a 
potential  divide  by  zero  should  have  a  formal  assertion  of  the  kind: 

C 

C  ..  Check  that  denominator  is  not  zero.  If  it  is,  do  not 

C    continue.  State  is  non-valid 


C 


IF  (DX.LT.SMALLJDX)  THEN 

MSG  =  'Invalid  DX  result.  Unable  to  continue  (CHK_DX).' 

CALL  FATAL  (MSG) 
ELSE 

HALF_X  =  XX  /  DX 
ENDIF 


Under  FORTRAN  77,  to  allow  for  the  code  to  execute  like  it  did  under  DG 
FORTRAN  5,  if  the  denominator  is  zero,  then  the  results  are  set  to  the 
numerator.   This  is: 


I 
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I 
I 
I 
I 


IF  (DX.LT.SMALL_DX)  THEN 

HALF_X  =  XX 
ELSE 

HALF_X  =  XX  /  DX 
ENDIF 


The  above  will  yield  the  same  results  as  those  of  the  old  DG  FORTRAN  5, 
however,  the  results  are  incorrect  !.  The  conversion  team  has  flagged 
this  type  of  error  wherever  found. 


Case  2 

Fixed  point  overflow: 

AOS/VS  CLI   Rev  07.54.00.00   27-MAR-87    14:13:29 
)  SEARCHLIST  : MACROS, :UTIL, : LANG: TCS 
)  DIRECTORY  :UDD:? ABDUL 
)  DEFACL  ? ABDUL, OWARE,+, RE 

) 

)  TYPE  TST.FR 

REAL  RVAL 
INTEGER  IBUFF 
RVAL  =  654399 
IBUFF=RVAL 
TYPE  IBUFF 
END 

) 

)  X  TST 
31807 

) 

) 

End  of  file 

AOS/VS  CLI   Terminating   27-MAR-87   14:13:30 

In  the  above  example  a  floating  point  number  (32  bits)  has  been 
assigned  to  an  integer  short  (16  bits).  The  code  did  not  halt  warning 
of  the  failure.  In  F77  this  code  would  cause  an  overflow  message.  In 
the  case  of  MOSS  this  type  of  operation  has  been  found  in  several 
places,  take   for   example  the  following  lines  from  the  routine  ADCORD: 

SUBROUTINE  ADCORD(IARR,NVERT,NREC,XXMIN,YYMIN, ICHAN, SCALE, IZZ) 

COMMON  /DEBUG/  IDEB 

COMMON  /lO/  NPRNT,IOIN 

COMMON  /CSTFC/   IZ,IPOINT,SC,XMIN,YMIN 

DIMENSION  IBUFF(128) 

DIMENSION  IARR(128),IR3(2) 

EQU IVALENCE  ( S  C , IR3 ( 1 ) ) 
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C   ENTER  TRANSFER  LOOP 
C 

DO  20  IP0INT=1,NVERT 
C 

K0UNT=K0UNT+1 
C 

XT=((X(IPOINT)-XMIN)/SC) 

YT=((Y(IPOINT)-YMIN)/SC) 

IF(IZ.EQ.l)  ZT=YR(IPOINT) 

XT=ANINT(XT) 

YT=ANINT(YT) 

IF(IDEB.NE.O)  WRITE (lOTABL(NPRNT), 2002)  XT,YT 
2002     FORMAT(1X,2F10.2) 

IC=IC+1 
IBUFF(IC)=XT 
IC=IC+1 
IBUFF(IC)=YT 


C 


RETURN 
END 


Note  that  IBUFF  is  defaulting  to  INTEGER*2.  If  SC  is  not  set  correctly 
XT  and  YT  would  overflow  IBUFF.  In  the  case  of  F0RTRAN5  it  is 
truncating  to  the  rightmost  16  bits  without  notifying  the  user  of  the 
problem.  In  the  case  of  F77  it  just  halts  with  a  fatal  system  error 
message. 


Case  3 

In  some  instances  the  conversion  discovered  cases  where  memory 
overwrites  are  not  detected  under  FORTRAN  5.  The  following  simple  case 
that  uses  RDLIN  from  ADS  is  trashing  memory  by  not  having  arrays 
dimensioned  properly: 

AOS  CLI   REV  07.01     9-APR-87      15:39:21 

)  SEARCHLIST  :UDD:BLMOP: CLIS , :UTIL, : , : C0MPILERS:F0RTRAN5 

)  DEFACL  WENDY, OWARE 

)  DOIT 

DIMENSION  IANS(1),JUNK(2) 

DATA  lANS  /2H   / 

DATA  JUNK/2H   ,2H   / 

OPEN  11,"0INPUT",ATT=="SIB" 

OPEN  10,"@OUTPUT",ATT="S0B" 

CALL  RDLIN   ( 11 ,IANS,ICNT,IER) 

WRITE  (10,9)  IANS,JUNK,ICNT 
9       FORMAT  ("NAME=",1A2,"  JUNK=" ,2A2,I5) 

CALL  EXIT 


I 
I 

I 


Moss  Conversion  Project  Page   14 


END 


YES 

NAME=YE  JUNK=S 
4 

) 
) 

END  OF  FILE 

AOS  CLI   TERMINATING    9-APR-87      15:39:27 


In  the  above  case,  if  the  user  answers  "YES"  to  a  prompt  where  at  the 
top  level  there  is  only  room  for  "YE",  a  memory  overwrite  is  caused. 
If  the  user  answers  "Y"  all  is  tidy.  Under  F77  this  memory  overwrite 
can  cause  a  pointer  fault  or  damage  a  subroutine  transfer  call. 


3.2.-  Errors  revealed  by  FORTRAN  77  and  PRIMPS 

If  and  when  a  part  of  the  MOSS  software  is  to  fail  with  a  system  error 
message  like: 

-  File  in  use 

-  Unit  not  open 

-  Stack  overflow 

-  Pointer  fault 

-  Illegal  segment  number 

-  File  already  exists 

-  Float  to  integer  overflow 

or  if  the  "procedure  "hangs"  the  things  that  may  be  causing  the  problem 
are  the  following: 

a)  Documentation  on  file  structures  does  not  agrees  in  several 
instances  with  the  actual  implementation.  For  example,  DESCRIBE. FA  is 
used  as  16  words  long  in  some  cases,  in  others  it  is  used  as  128  words. 
This  would  work  fine  on  the  DG  which  allows  mixture  of  file  types  and 
I/O  handling  modes.  It  does  not  work  on  the  PRIME  where  more  strict 
rules  about  file  handling  are  enforced  (e.g.  mixing  of  RDSEQ  with 
WRITE  BINARY,  WRBLK  with  simple  FORTRAN  READ,  etc.) 

b)  Routines  calling  other  routines  with  wrong  number  of  parameters 
creating  a  pointer  fault. 

c)  Arrays  being  declared  as  two  dimensional  and  then  handled  as  one 
dimensional  throughtout  the  code,  creating  a  memory  overwrite  codition. 

d)  Routines  calling  routines  with  constants  and  then  the  "called" 
routine  overwriting  the  constant  upon  return  creating  an  access 
violation. 

e)  Arrays  indexed  out  of  bounds  creating  a  frame   stack-crawl   out,   or 
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causing  the  process  to  "hang". 

f)  Mixing  of  file  types.  Sequential  with  direct  access.  Opening  a 
file  read  only  and  then  writing  to  it.  Improper  handling  of  channel 
numbers.   Leaving  channels  open  when  exiting  process. 

g)  Code  redundancy.  There  are  multiple  copies  of  the  same  routine 
throughout  the  system  violating  the  integrity  of  the  software  data 
base.  Routines  with  the  same  name  and  function,  varying  in  number  of 
parameters . 

h)  Violation  of  the  concepts  of  information  hiding  and  module 
implemented  in  packages  like  TCS  by  accessing  and  altering  the  contents 
of  the  common  blocks.   This  makes  difficult  to  debug  the  code. 

1)  Uninitialized  variables,  e.g.   counters.   On  the  DO  F0RTRAN5  these 

are  defaulted   to   zero.    In  F77   the  value   is   undefined  or  just 

"garbage".  This  can  cause  an  array  out  of  bounds  condition  or  a 
process  taking  the  wrong  branch. 

j)  On  the  DG  ASCII  data  has  the  standard  high  bit  OFF.  On  the  PRIME 
the  high  bit  is  ON.  The  MOSS  code  has  "hard-wired"  ASCII  constants  in 
many  places  for  parsing  or  checking  for  certain  conditions.  Since  in 
F0RTRAN5  the  CHARACTER  data  type  did  not  exist,  character  strings  are 
handled  via  integer  arrays  and  hollerith  expressions.  In  this  sense  an 
evaluation  for  blank  like  this: 

IBLANK  =  '  ' 


IF  (IBLANK  .EQ.  32)  GOTO  10 

has  to  be  converted  to 

IF  (IBLANK  .EQ.  160)  GOTO  10 

This  point  of  the  high  bit  ON  vs.  high  bit  OFF  is  a  very  important  one 
and  has  been  probably  the  most  cumbersome  to  overcome  in  the  conversion 
process. 

k)  Do  loops  in  the  code  have  caused  the  software  to  hang.   For   example 

IF  (lANSWER.NE.'Y')  GOTO  20 

DO  20  K=1,N 

20  CONTINUE 

At  the  point  of  the  20  CONTINUE  entry,  K  is  undefined.  In  F77  this 
will  cause  an  "infinite"  loop  (this  is  known  as  "jumping  into  the  range 
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of  a  DO  loop").   Another  example  that  can  cause  a  different  problem  and 
related  to  the  DO  is  the  following: 

DO  20  K=1,0 


20  CONTINUE 

Under  F0RTRAN5  this  loop  will  be   executed   once, 
executed  under  F77.   Results  are  unexpected. 


It  will  never  be 


The  award  winning  blunder  in  the  code  was  found  in  an  AMS  routine.   An 
extract  of   the  code  is  the  following  (see  if  you  can  detect  problem): 

SUBROUTINE  EMUL  (IFLAG) 


C 

7004 

51 
56 


5001 
53 


57 
58 

52 


IF  (.NOT. VALID)  TOITE  (LU1,7004)  II.IBCODE 
FORMAT  ('   CHARACTER  ',12,'  IS  BAD  =  ',113) 
IF  (.NOT. VALID)  GOTO  56 
CONTINUE 
CONTINUE 
IF  (VALID)  GOTO  52 

THEN  -  this  is  not  a  valid  input  string  from  table 

WRITE  (LU1,5001) 

FORMAT  ( '  MEASUREMENT  NOT  ACCEPTED  -  TRY  AGAIN  ! ' ) 

CONTINUE 

IF  (1  .EQ.  0)  GOTO  58 

THEN  -  bell  is  turned  on 
DO  57  1=1,  2 

CALL  WRSEQ  (LU1,BELL,2,IEE) 
CONTINUE 
CONTINUE 

CALL  SITE  (LU1,9999,CDATA,IRR,IER) 
CONTINUE 


I 
I 
I 


9000   RETURN 
END 

If  you  were  unable  to  find  the  "bad"  instruction  here  it  is: 

IF  (1  .EQ.  0)  GOTO  58 

as  you  can  see,  there  is  something  wrong  about  it  !. 

The  above  examples  are  but  a  few  of  the  many  encountered  during  the 
conversion.  It,  however,  is  a  comprenhensive  set  of  samples  that  give 
an  accurate  description  of  the  code  problems  present   in   the   software 
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data  base. 


4 .-  What  next 

On  April  10,  1987,  5995  man/hours  later  (almost  3  man/years),  the  MOSS 
conversion  project  had  successfully  met  it's  delivery  date  and  passed 
all  the  government's  quality  assurance  tests. 

During  the  delivery  of  the  software  on  the  week  of  April  6,  I  had  the 
opportunity  to  meet  with  the  government's  technical  group  for  the 
future  maintenance  of  the  software.  I  personally  think  that  this 
software  has  no  future  unless  it  is  re-written.  Here  are  several 
observations: 

a)  User  Interface  The  user  interface  is  not  consistent  throughout  the 
code.  There  are  multiple  parsers.  In  some  instances  you  answer  "Y"  or 
"N";  in  others  "YES"  or  "NO";  while  in  others  (1=YES  /  0=NO) .  Error 
recovery  is  poor  or  non-existent.  Some  menus  force  you  to  answer 
"something"  before  you  can  exit.  Although  the  feature  of  mixing  a 
command  driven  parser  with  a  prompt  driven  parser  is  a  good  one,  it 
loses  it's  value  in  poor  implementantion.  In  technological  terms,  the 
user  interface  is  obsolete;  menu  design  and  implementation  is  not 
present.  To  obtain  such  a  capability,  a  new  user  interface  has  to  be 
written.  I  think  one  of  my  biggest  fits  with  the  code  was  when  we 
finally  were  able  to  export  some  maps  from  the  DG  to  the  PRIME.  The 
MOSS  IMPORT  program  finished  then  and  asked  if  I  wanted  to  delete  the 
input  map.  I  said  no  (in  lower  case).  It  defaulted  to  delete  the  map 
!. 

b)  Data  structures  and  data  models  Because  there  are  no  definition  or 
implementation  of  concepts  of  tight  coding,  encapsulation,  module  and 
information  hiding  it  is  difficult  to  talk  about  data  structures.  In 
any  case,  the  adopted  file  definitions  are  very  heterogeneous  across 
system  programs.  In  general  MOSS  provides  the  user  with  a  rudimentary 
flat  file  structure  and  a  redundant  polygon  vs.  ARC  data 
representation  method.  One  can  not  precisely  conceptualize  a  given 
data  model  used.  The  redundancy  used  in  the  system  will  cause  the  data 
base  to  corrupt. 

c)  Algorithms  Functionally  speaking  the  MOSS  family  of  programs 
ressembles  a  GIS.  The  algorithmic  redundancy  in  the  code  is  rather 
fascinating,  e.g.  several  point-in-polygon  routines,  several  ways  of 
doing  overlay,  various  methods  for  digitizing,  contouring,  rasterizing, 
etc..  It  is  unfortunate  however  to  find  that  not  one  method  is 
reliable.  This  algorithmic  excess  can  only  but  create  confusion  from 
the  maintenance  point  of  view.  For  the  user  it  is  a  total  nightmare: 
should  I  use  OVERLAY,  GOVERLAY,  BLMOVER  or  PLOVER  ?!. 
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5.-  Conclusions  and  recommendations 

The  MOSS  conversion  project  was  succesful  in  migrating  the  family  of 
software  from  the  DG  and  FORTRAN  5,  to  the  PRIME  and  FORTRAN  77.  In 
the  process  it  revealed  the  conditions  in  which  the  code  was 
functioning.  One  can  say  that  the  software  now  will  be  less  flaky  and 
pronounce  itself  by  halting  with  a  hard  error.  In  many  instances,  the 
Data  General  under  FORTRAN  5  would  not  halt  a  program  had  a  major  error 
occurred  internally. 

The  EROS   Data   Center   Report   on   "An  Evaluation   of  Vector   Based 

Geographic   Information  Systems  At  The  Eros  Data  Center"   (David 

Greenlee,  Jan  Van  Roessel  and  Michael  Wehde,  1986)   has  some  implicit 

results  that  are  to  be   seriously  considered  about  MOSS.   One  can 

conclude  from  this  report  that  one  of  the  main  problems  of  MOSS  et.al. 
is  it's  lack  of  robustness.  Who  cares  how  flashy  or  easy  to  use  a 
system  is  if  it  does  not  work  ! . 

A  1984  EDC  study  ("A  Study  of  MOSS  and  ID IMS:  The  FMLIS  Pilot  Project 
Example)  concluded  that  MOSS's  most  serious  problem  were  related  to 
spatial  recategorization  and  overlay  functions. 

"The  Feasibility  and  Design  Study  for  the  Enhancement  of  MOSS"  produced 
by  Autometrics  in  1984  for  the  USGS  is  an  accurate  assesstment  of  the 
changes  the  software  has  to  go  through.  It  is  worthwhile  noting 
however,  that  before  any  enhancements  can  occur,  the  current  state  of 
the  software  can  only  but  get  in  the  way  of  changes.  The  software  has 
to  be  modularized  to  make  maintainability  efficient;  the  algorithms 
need  to  be  revised/re-written  to  be  made  reliable;  the  data  structures 
need  to  be  changed  from  polygon  based  to  ARC/NODE;  realistic  attribute 
handling  has  to  be  added;  DBMS  facilities  have  to  be  incorporated  with 
the  ability  for  spatial  searching,  and  on  and  on. 

Designing  and  implementing  a  software  system  is  a  neverending  task. 
Our  experience  with  the  software  life  cycle  shows  careful  design  to  be 
critical  because  this  initial  stage  will  always  be  re-visited:  all 
software  architectures  have  a  curve  of  diminishing  returns.  As  the 
structure  grows  it  can  interfere  with  system  efficiency.  When  this 
happens,  it  is  time  to  expand  the  design  criterion  and 
re-configure/modify  the  present  architecture.  In  the  case  of  MOSS, 
this  is  quite  difficult  since  there  are  no  clear  architectural  design 
concepts. 

In  the  initial  design  phase  of  a  system,  maintainability  is  a  main 
issue.  In  our  experience,  most  maintenance  is  caused  by  changing 
requirements  rather  than  by  reliability  problems  (this  is  true  with  a 
robust  system).  Maintenance  is  key  to  the  software  life  cycle  since  it 
involves: 

-  Error  and  design  defect  correction 

-  Design  improvement 
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-  Software  performace  improvement 

-  Software  conversion  to  different  hardware  platform,  use 
state-of-the-art  hardware   features,  telecommunications 
facilities,  station  configurations,  etc. 

-  Software  interface  to  other  systems 

-  Data  base  architecture  changes 

-  Application  changes  or  enhancements. 


From  the  experience  of  the  conversion,  my  conclusion  is  that  MOSS  has 
served  it's  time  and  is  ready  to  be  retired.  If  this  approach  is  not 
taken,  the  effort  spent  in  "fixing  it"  will  go  beyond  any  time 
scheduled  and  allocated  budget.  In  the  long  run,  it  will  be  better  to 
license  a  well  known  and  reliable  GIS  product. 

To  conclude,  I  think  the  key  issue  that  comes  up  is  whether  or  not  the 
government  wants  to  be  in  the  GIS  software  research  and  development 
business ,  allocate  the  time,  funds,  and  commitment  to  the  enterprise, 
and  support  the  user  community  with  the  appropriate  system  maintenance, 
documentation  and  upgrades. 
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INTRODUCTION 


The  Coastal  Management  Division  (CMD)  of  tine  Louisiana  Department  of  Natural 
Resources  is  legally  mandated  to  control  permitting  of  certain  activities  in  the  Louisiana 
Coastal  Zone.  The  Coastal  Zone  is  approximately  the  five  foot  contour  in  southern 
Louisiana  and  comprises  about  5  million  acres.  The  regulation  is  designed  to  balance 
both  the  economic  use  of  the  area  as  well  as  its  environmental  health.  The  mechanism 
used  for  this  regulation  is  permitting.  Approximately  1500  permit  applications  are 
received  each  year.  Analysis  of  permits  requires  knowledge  of  the  environmental  and 
cultural  conditions  of  the  affected  area.  This  information  exists  on  a  combination  of  about 
4000  maps,  charts,  Landsat  scenes  and  aerial  photographs  which  are  used  by  CMD 
analysts.  CMD  has  a  Data  General  MV/10000  computer  with  AMS,  MOSS,  ERDAS  and 
FORTRAN  software  systems  on  which  a  large  portion  of  the  maps  have  been 
computerized  and  are  available  to  MOSS. 

This  paper  describes  the  automated  system  that  was  developed  by  Decision 
Associates,  Inc.  for  CMD  under  a  grant  from  the  NOAA  Office  of  Oceans  and  Coastal 
Resource  Management.  The  system  consists  of  a  set  of  linked  programs  that 
automatically  performs  an  analysis  of  a  site  for  permit  review  evaluation.  This  paper  is 
divided  into  5  parts  related  to  the  automation  of  permit  analysis: 

1.  MOSS  Automatic  Permit  Analysis  System --  an  overview; 

2.  Map  Index  Program  (  MIP  ); 

3.  MOSS  Command  Interpreter  (  MCI ); 

4.  Remote  execution  of  the  MOSS  system  using  a  Macintosh™; 

5.  A  Decision  Tree  for  Coastal  Use  Guideline  Analysis. 
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.....      OVERVIEW  OF  AUTOMATIC  PERMIT  ANALYSIS      •— 

Permit  analysis  requires  GIS  functions  such  as: 

A.  Identification  of  tlie  maps  on  which  the  permit  site  occurs; 

B.  Proximity  searches  in  the  vicinity  of  the  site; 

C.  Location  of  sensitive  and  prohibited  areas  relative  to  the  site; 

D.  Location  of  other  permitting  activities  in  the  area; 

E.  Habitat  change  detection  and  acreage  calculations; 

F.  Statistical  analysis; 

G.  Printed  output  of  geographic  data  and  analyses; 

H.  Graphical  hardcopy  of  the  maps  and  special  areas  of  interest. 

We  have  automated  portions  of  the  CMD  permitting  process.  This  was  accomplished 
by  the  use  of  many  computer  system  MACROS,  a  Map-Indexing  Program  (MIP)  and  a 
MOSS  Command  Interface  (MCI).  The  output  of  this  process  is  discussed  below,  but  we 
feel  that  an  overview  is  in  order.  The  permit's  geographic  location  is  given  to  the 
Map-Index  Program  along  with  two  pieces  of  identifying  information.  The  MIP 
geographically  locates  the  study  area  and  determines  the  computer  maps  that  are 
appropriate.  After  doing  its  own  analysis,  this  information  is  then  passed  to  the  MOSS 
Command  Interface  (MCI)  which  creates  a  command  file  for  MOSS  and  automatically 
executes  MOSS  using  this  command  file.  No  direct  user  interaction  with  MOSS  is 
required.  By  using  this  process,  approximately  95%  of  the  questions  that  MOSS  would 
normally  ask  are  not  posed  for  the  user.  The  user  is,  therefore,  not  required  to  know  the 
names  or  syntax  of  the  MOSS  commands  nor  the  order  in  which  they  must  be  executed  to 
accomplish  the  desired  analysis.  Thus,  routine  MOSS  analyses  can  be  run  by  a 
technician,  thereby  freeing  the  permit  analyst  for  evaluation  of  results  and  other  tasks. 

As  an  example,  to  obtain  A  through  H  above  for  a  radial  proximity  search,  about  35 
computer  commands  and  90  MOSS  commands  would  be  required.  These  MOSS 
commands  require  over  200  responses  for  arguments.  Using  the  Map-Index 
Program/MOSS  Command  Interface  (MIP/MCI)  system,  only  4  of  the  over  300  responses 
are  required  of  the  user.  Furthermore,  the  questions  asked  to  obtain  this  information  are 
stated  in  familiar  terms  thus  avoiding  confusion  and  mistakes. 

The  above  discussion  pertains  to  an  AUTOMATED  analysis  which  is  run  on  a  daily 
basis.  In  addition,  other  types  of  analyses  can  be  performed  using  the  MIP  and  MCI  and 
are  discussed  below.  These  analyses  would  be  useful  in  special  cases  where  linear 
features,  polygonal  study  areas,  economic  or  special  areas  are  encountered. 

The  MIP  can  be  used  on  a  routine  basis  to  aid  CMD  personnel  in  identifying  and/or 
locating  geographic  information.  It  is  also  an  aid  to  the  many  outside  people  who  use  the 
resources  of  the  office.  Besides  identifying  relevant  maps,  the  MIP  also  prints  a  list  of 
navigation  charts,  photographs  and  LANDSAT  data  sources  on  file  of  a  specific  site. 
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DESCRIPTION  OF  AUTOMATIC  MOSS  ANALYSIS  OUTPUT 

The  following  section  is  included  to  provide  an  example  of  analysis  products 
routinely  produced  by  the  Automatic  Permit  Analysis  System.  The  reader  is  referred  to 
the  example  output  following  the  paper.  This  is  the  actual  output  with  the  exception  for 
the  compression  used  to  reduce  the  number  of  pages.  The  map  index  allows  the 
identification  of  any  permit  site  on  the  appropriate  map  in  the  data  base  with  the  input  of  a 
latitude/longitude  location.  Any  map  type  occurring  in  that  location  can  be  identified  and 
automatically  retrieved  using  a  standard  map  area  index  moniker.  The  analysis  is  then 
accomplished  by  performing  a  proximity  radius  search  of  variable  size  on  the  data  in 
question.  Comparisons  are  made  of  two  years  to  produce  change  statistics  for 
environmental  habitats.  Also,  sensitive  environmental  areas  in  the  radius  are  flagged, 
and  other  permit  locations  in  the  proximity  are  identified  and  reported  from  a  multiattribute 
file.  Area  tables  and  change  table  statistics  are  produced  and  hardcopy  vicinity  maps  and 
proximity  maps  are  generated  -  all  automatically. 

A  set  of  output  from  the  Automatic  Permit  Analysis  System  is  included  at  the  end  of 
this  paper.  This  set  has  been  pared  down  by  removing  some  sets  of  similar  analyses  and 
maps  have  been  reduced  and  combined  on  pages  to  conserve  space.  A  copy  of  the 
actual  output  is  available  from  the  authors.  The  sample  output  of  consists  of: 

A.   A  title  page  with  the  original  input  plus  other  data  determined  by  the  MIP; 


MIP 


B. 
C. 

D. 

E. 


F. 


A  title  line  for  the  MIP  output; 

Reiteration  of  the  input  parameters; 

The  UTM  coordinates  of  the  study  area; 

Up  to  six  sets  of  information  detailing  the  the  appropriate  maps  including; 

1.  The  description  of  the  map  series  currently  being  reported  on; 

2.  The  map  number  designation  given  the  particular  map  by  CMD; 

3.  The  USGS  map  name; 

4.  The  moniker  or  prefix  used  to  name  the  computer  file  containing  the  map; 

5.  The  map  ratio  and  interval  scales; 

6.  The  three  closest  adjacent  maps  (  all  eight  are  obtainable  as  an  option  ); 

7.  The  ground  distance  from  the  permit  location  to  the  edge  of  the  map; 

8.  The  map  distance  from  the  permit  location  to  the  edge  of  the  paper  map; 

9.  A  list  of  all  hardcopy  maps  that  CMD  actually  has  in  house. 
All  Landsat  TM  scenes  which  include  the  permit  location  along  with; 

1 .  The  approximate  center  of  the  Landsat  scene; 

2.  The  scene  quadrant  in  which  the  permit  site  is  located; 

3.  The  name,  date  and  CMD  number  of  the  scene; 

4.  The  scene  ID; 

5.  The  magnetic  tape  number  where  the  scene  is  stored. 
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G.   Five  sets  of  information  pertaining  to  photographs  likely  to  be  of  the  most  use; 

1 .  The  series  name  of  the  photographs; 

2.  The  maximum  search  radius  for  photo  centers; 

3.  The  approximate  scale  and  the  interval  scales  of  the  photographs; 

4.  The  nine  photos  whose  centers  are  closest  to  the  permit  sorted  by  distance. 
H.  The  file  names  of  all  computer  readable  maps  on  the  system. 

MCI 

J.  A  MOSS  AREA  summary  of  the  proximity  circle  (p.c.)  for  the  1 956  data; 

K.  A  MOSS  AREA  summary  of  the  p.c.  for  the  1 978  data; 

L  A  report  on  the  changes  occurring  between  the  1956  and  1978  data; 

M.  A  report  on  any  linear  features  found  within  the  p.c; 

N.  A  report  of  any  polygonal  environmental  sensitive  features  within  the  p.c; 

O.  A  multiattribute  report  on  all  previously  requested  permits  within  the  p.c; 

P.  A  MOSS  AUDIT  of  the  1956  habitat  polygons; 

0.  A  MOSS  AUDIT  of  the  1978  habitat  polygons; 

R.  A  PLOT  of  the  appropriate  1978  7.5  min  quad  with  the  p.c.  superimposed; 

S.  A  PLOT  of  the  1956  p.c.  with  the  habitat  polygons  labeled; 

T.  A  PLOT  of  the  1978  p.c  with  the  habitat  polygons  labeled; 

U.  A  PLOT  of  the  p.c  with  previously  requested  permits  numbered; 

V.  A  SHADEd  PLOT  of  the  1 978  p.c  coded  for  habitat  type. 


Other  inventory  information  is  generated  as  well,  and  new  data  variables  are 
continually  being  added,  improvements  developed  but  not  yet  added  to  the  automated 
analysis  include  a  routine  that  allows  the  automatic  and  very  rapid  shading  of  a  map. 
This  same  routine  will  also  aggregate  subjects,  thus  enabling  habitat  categories  to  be 
generalized  when  needed.  Also  ready  for  inclusion  in  the  automated  generation  is  a 
proximity  analysis  obtained  from  the  classified  Landsat  TM  data  of  the  Louisiana  Coastal 
Zone  which  was  recently  completed  by  Decision  Associates. 

In  summary,  the  procedure  described  above  requires  only  the  latitude,  longitude 
location  and  two  identifying  items.  It  then  runs  unattended  to  produce  the  output  products 
attached.  No  direct  interaction  is  required.  In  actuality,  we  have  taken  the  process  one 
step  further  in  that  we  allow  the  user  to  batch  any  number  of  requests  and  have  the  whole 
series  run  to  completion.  One  analysis  takes  from  15  to  25  minutes  and  CMD  runs  an 
average  of  six  per  day.  This  number  is  down  from  its  previous  levels  due  to  the  decrease 
in  oil  exploration. 
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MAP  INDEX  PROGRAM 
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As  mentioned  earlier,  permit  analysis  requires  reference  to  a  large  amount  of 
geographic  data  to  assess  environmental  and  cultural  conditions.  For  this  reason,  CMD 
houses  an  extensive  collection  of  geographic  reference  materials.  Because  of  the  large 
size  of  the  collection,  there  was  a  need  to  create  a  database  to  improve  access.  The  maps 
were  geographically  cataloged  and  organized  for  cross-indexing  via  computerized 
search,  retrieval  and  report  generation.  The  user  has  only  to  specify  the  geographic 
coordinates  of  a  location  and  the  system  will  present  a  summary  of  all  relevant  materials. 
Output  from  this  program  is  a  list  of  all  hardcopy  and  computerized  maps,  charts,  Landsat 
data  and  photographs  of  the  study  area  along  with  information  used  to  physically  locate 
the  permit  position  on  hardcopy  maps.  Also  printed  is  a  list  of  all  the  names  of  the 
computer  maps  available  of  the  study  area.  This  output  has  been  described  in  more  detail 
earlier. 

The  MIP  is  used  on  a  routine  basis  to  aid  the  CMD  personnel  in  identifying  and/or 
locating  geographic  information  without  initiating  an  automated  analysis.  It  is  also  an  aid 
to  the  many  outside  people  who  use  the  resources  of  the  office. 


MAPS 

The  database  consists  of  two  types  of  information.  The  first  --  the  AREA  FILE  --  is  a 
set  of  all  USGS  map  formats  which  cover  the  Louisiana  Coastal  Zone.  Information  for 
each  quadrangle  includes  the  minimum  bounding  rectangle,  adjacent  map  pointers,  CMD 
reference  number,  scale  and  name.  Note  that  these  data  are  generic  --  they  contain  no 
references  to  actual  hardcopy  products.  The  second  part  of  the  database  --  the  MAP  FILE 
--  contains  one  record  for  each  existing  hardcopy  map  product  actually  in  CMD's 
possession.  These  records  contain  the  map  type,  date  and  storage  location  and  are 
linked  to  the  AREA  FILE  by  the  CMD  reference  number.  When  the  user  specifies  a 
geographic  coordinate,  the  MIP  locates  the  generic  area  using  the  MBR's  in  the  AREA  file, 
obtains  the  CMD  reference,  and  reports  on  all  products  in  the  MAP  file  with  this  number. 

The  AREA  file  includes  the  following  map  formats  : 

1  /  24,000  QUAD  SCENE    =  7.5  MINUTE  QUAD 
1  /  63,500  FULL  SCENE     =  15  MINUTE  QUAD 
1  /  80,000 
1  7100,000 
1  /  250,000 
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The  MAP  file  includes  the  following  map  types  that  exist  at  CMD: 

0  Topographic 

0  1 956  Habitats 

0  1978  Habitats 

0  Oyster 

0   Socio-economic 

0  Mineral 

0  Soil  &  geomorphology 

0  Climate  &  hydrology 

0  Active  processes 

0  Biological 


AERIAL  PHOTOGRAPHS 

Because  no  standard  area  scheme  exists  for  aerial  photographs,  it  was  not  possible 
to  construct  an  AREA  file  for  them  and  they  were  handled  differently.  For  each  photo 
in-house,  a  record  was  created  containing  its  geographic  center  point,  format,  scale, 
storage  location,  series,  date,  roll,  frame  and  CMD  numbers.  Because  it  is  difficult  to 
georeference  photos,  -only  the  center  is  in  the  index.  When  searching  for  photos  that 
might  be  relevant  to  the  site  under  investigation,  the  scale  is  used  in  conjunction  with  the 
center  to  establish  a  search  radius  that  is  equivalent  in  miles  to  1.5  times  the  diagonal  of 
the  photograph.  Within  this  search  radius,  the  nine  nearest  photos  are  identified  and 
reported  in  order  of  increasing  distance  from  the  site. 

The  series  that  currently  exist  at  CMD  are: 

NASA74  EPA74  NASA78  NHAB  NASA85 


LANDSATTMDATA 

A  situation  similar  to  the  aerial  photos  exists  with  the  Landsat  TM  data  in  that  no 
exact  area  scheme  exists.  For  this  data,  the  scene  corner-point  coordinates  were  stored. 
This  allowed  the  MIP  to  place  the  site  in  the  proper  Landsat  scene(s).  Data  for  each 
scene  includes  the  scene  id,  path,  row,  date,  format,  storage  location  and  magnetic  tape 
number  on  which  the  scene  is  stored. 
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MOSS  COMMAND  INTERFACE 


The  permit  analysis  process  requires  certain  time-consuming  and  repetitive  functions 
tiiat  can  be  performed  by  a  computerized  system  such  as  MOSS.  Automation  of  these 
functions  would  result  in  speeding  up  the  permit  process  and  thereby  allow  the  analyst 
additional  time  to  apply  his  expertise  in  more  important  areas.  Furthermore,  the  computer 
operations  required  to  accomplish  these  tasks  can  be  automated  to  the  extent  that  very 
little  input  is  required  to  accomplish  a  series  of  analysis  procedures. 

The  permit  analysis  procedures  used  by  the  CMD  analysts  were  documented  from 
the  Coastal  Use  Permit  Review  Sheet,  and  the  tasks  that  required  reference  to  maps  or 
location  data  were  identified.  Although  many  permit  analysis  functions  are  possible  to  do 
on  the  computer,  several  are  obvious  and  of  much  value  to  the  reviewer.  These  include 
but  are  not  limited  to: 

0  Plotting  a  map  for  visual  inspection,  query  and  measurement; 

0  Performing  a  radius  proximity  search  for  habitat  types,  ecological,  sensitive  areas, 

other  permit  sites,  endangered  species,  archaeological  sites,  etc.; 
0  Comparison  of  two  dates  in  the  same  region  for  change  detection; 
0  Statistical  analysis  and  acreage  calculations; 
0  Identification  of  maps  on  which  a  site  is  located. 

MOSS  command  sequences  were  developed  to  accomplish  the  specific  functions  of 
the  permit  review  process  that  required  references  to  computerized  habitat  maps, 
sensitive  area  maps  and  existing  permit  applications.  Menu  items  were  devised  to  reflect 
the  information  requirements  for  permit  analysis  such  as  the  types  and  acreage  of 
ecological  habitats  in  the  area,  the  location  of  ecological  sensitive  areas  in  the  vicinity  of 
the  site,  the  change  that  has  taken  place  from  1956  to  1978  in  habitats,  and  the  location 
and  type  of  other  permits  within  the  region.  Many  more  such  customized  procedures  can 
be  added  to  the  menu  list.  Current  menu  selections  generate  hard  copy  output  maps  of 
the  search  radius,  statistical  tables  of  areal  information,  and  reports  on  multiattribute  file 
contents. 

MOSS  incorporates  a  powerful  Geographic  Information  System  (GIS),  however,  the 
ability  to  use  this  software  is  dependent  upon  the  user  being  familiar  with  a  number  of 
concepts.  For  the  unfamiliar,  using  MOSS  can  be  likened  to  flying  a  jet  plane  where  the 
controls  are  labeled  in  a  foreign  language.  The  MOSS  user  is  normally  required  to 
understand  not  only  his  problem,  but  also  the  commands  that  are  necessary  along  with 
their  sometimes  obscure  arguments  and  the  complicated  sequences  that  are  often 
necessary.  For  these  reasons  it  was  decided  to  construct  a  user  interface  to  MOSS. 
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There  were  many  objectives  in  the  development  of  this  interface.  These  were 
primarily  aimed  at  simplifying  and  speeding-up  MOSS  analysis  while  providing  the  ability 
to  run  repetitive,  routine  jobs  with  the  use  of  technicians.  It  was  important  to  modify 
MOSS  program  code  as  little  as  possible.  These  objectives  also  included  the  following: 

0  Automatic  production  of  hard  copy  products; 

0  Handling  the  problem  of  adjacent  maps; 

0  That  little  or  no  knowledge  of  MOSS  be  required; 

0  The  MOSS  analysis  be  transparent  to  the  user; 

0  The  system  be  user-friendly  and  fault  tolerant; 

0  The  ability  to  have  helpful  messages; 

0  The  ability  to  renjn  a  series  of  steps  with  little  work; 

0  To  converse  with  the  user  in  familiar  terms  &  English; 

0  The  full  use  of  MOSS  capability; 

0  The  ability  to  run  routine  analyses  unattended  --  a  corollary  to  this  is  that  all  input 

is  entered  immediately  upon  execution  so  that  an  analysis  that  may  require 

commands  every  hour  does  not  require  a  attendant. 

The  first  section  of  this  paper  pertains  to  an  AUTOMATED  PERMIT  ANALYSIS 
which  is  run  on  a  daily  basis.  In  addition,  other  types  of  analyses  can  be  performed  using 
the  MCi.  These  analyses  are  useful  in  special  cases  where  linear  features,  economic  or 
special  areas  are  encountered.  The  MCI  can  be  used  to  investigate  unusual  or  special 
situations  as  well  as  for  those  permits  of  a  sensitive  nature  where  a  more  detailed 
evaluation  is  required.  The  user  of  the  MCI  is  presented  with  a  menu  of  choices  from 
which  it  is  only  necessary  for  her  to  select  the  appropriate  analysis  type.  The  MCI  then 
requests  the  minimal  required  information.  Those  questions  asked  by  the  MCI  are 
tailored  to  the  user  in  an  English  sentence  style.  Approximately  90%  of  the  questions  are 
eliminated  and  no  detailed  knowledge  of  MOSS  is  required.  Additional  MCI  commands 
can  be  added  by  someone  knowledgeable  in  MOSS  with  no  programming  required. 

The  Data  General  computer  operating  system,  AOSA/S,  allows  the  user  to  create  a 
set  of  commands  followed  by  their  input  and  store  this  sequence  of  lines  on  disk. 
Execution  is  begun  by  using  a  /M  "switch"  on  the  execute  command.  It  is  therefore 
possible  to  create  a  disk  file  with  all  the  desired  commands  and  input  and  cause  them  to 
be  executed  by  simply  typing  the  name  of  the  disk  file.  The  method  used  was  to  write  a 
FORTRAN  program  that  presented  the  user  a  menu,  asked  a  few  English-type  questions 
and  then  created  a  disk  file  with  all  the  dialogue  required  to  perform  the  task  desired. 
This  procedure  relieves  the  user  of  the  burden  of  being  familiar  with  MOSS  commands, 
command  sequences,  syntax  and  nomenclature.  It  also  eliminates  the  need  for  him  to 
invent  and  maintain  numerous  temporary  disk  files.  The  interface  program  also  allows  for 
the  introduction  of  simple  English  syntax  questions  when  the  user  must  be  asked  for 
information.  The  program  to  interface  with  MOSS  has  been  termed  the  MOSS  Command 
Interface  (MCI). 
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The  MCI  uses  the  following  technique: 

1.  The  user  logs  on  and  the  MCI  program  is  automatically  invoked; 

2.  A  menu  of  choices  is  read  from  disk  and  presented; 

3.  The  user  chooses  an  entry  by  number; 

4.  The  MCI  reads  and  interprets  directives  given  in  a  skeleton  command  file 

named  TYPEnn.CMD  where  nn  is  the  menu  choice  selected; 

5.  The  user  is  queried  for  required  data; 

6.  The  MCI  makes  the  appropriate  substitutions  in  the  skeleton  command; 

7.  The  MCI  then  creates  a  file  named  MCI.CMD.CLI  and  writes  into  it  all  the 

commands  and  dialogue  required  to  run  MOSS; 

8.  This  file  is  then  executed  whereby  the  analysis  is  performed. 

It  was  necessary  to  make  one  change  in  MOSS  however.  When  plotting,  the  MOSS 
PLOT  routine  uses  multi-tasking  to  monitor  the  keyboard  to  allow  the  user  to  abort  the  plot 
job.  More  specifically,  MOSS  monitors  the  input  device  -  usually  the  keyboard  -- 
looking  for  an  abort  command.  In  our  case,  however,  the  input  device  was  a  disk  file.  It 
was  necessary  to  defeat  this  "looking"  to  prevent  MOSS  from  reading  and  discarding  all 
the  rest  of  the  data  in  the  disk  file  that  is  used  as  input  in  our  case. 

Initially,  attempts  were  made  to  invoke  command  sequences  via  the  MOSS  BUTTON 
command.  After  extensive  attempts  at  doing  this,  it  was  decided  that  the  'BUTTON' 
approach  would  not  be  feasible  because  of  two  major  factors.  The  first  was  due  to  the  fact 
that  MOSS  command  sequences  within  the  BUTTON  formats  were  limited  to  80 
characters.  This  is  far  short  of  what  was  needed.  Secondly,  MOSS  commands  generate 
a  large  number  of  prompted  responses,  many  of  which  do  not  have  obvious  or  easily 
understood  arguments.  Consequently,  this  led  to  a  decision  to  abandon  use  of  the 
BUTTON  commands  in  favor  of  the  above  approach  that  provided  an  interface  between 
the  user  and  MOSS  with  a  menu  format. 


MOSS  EXECUTION  VIA  A  MACINTOSH 


We  have  recently  setup  a  remote  MOSS  workstation  using  a  Macintosh  as  the 
remote  terminal.  This  setup  was  employed  to  run  the  Automated  Permit  Analysis  System. 
The  cost  of  this  machine  was  about  $3,000  for  both  hardware  and  software.  The  software 
used  was  a  terminal  emulation  program  named  VersaTerm  Pro™  written  by  Lonnie 
Abelbeck.  Besides  being  a  superb  terminal  program  full  of  features,  VersaTerm  Pro  has 
the  ability  to  emulate  four  different  terminals.  These  are  the  DEC  VT100,  Data  General 
D200,  Tektronix  4014  and  the  Tektronix  4105  --  a  combination  of  unique  utility  to  the 
MOSS  community.  This  particular  combination  of  features  is  such  an  attractive  way  to 
work  that  we  have  on  occasion  used  the  Mac  locally  for  documentation  purposes  --  this 
paper  for  example.  The  MacA/ersaTerm  runs  at  9600  baud  very  nicely. 
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Using  the  Mac  as  a  terminal  offers  some  outstanding  benefits.  Tine  maps  can  be 
saved  on  disk  and  tiien  manipulated  and  included  in  a  database  or  textual  report  with  the 
proper  software.  Additional  advantages  include: 

0  Inexpensive  as  it  replaces  both  text  and  graphic  terminals; 

0  Even  less  expensive  if  you  already  have  a  Mac  -  VersaTerm  Pro  costs  $295; 

0  Takes  less  room  for  the  same  reason; 

0  Can  do  local  processing; 

0  Can  get  LaserWriter  output; 

0  Can  print  color  maps  using  Imagewriter  II  and  a  color  printing  program; 

0  Can  customize  maps  by  pattern  filling,  scaling,  etc.; 

0  Can  emulate  a  color  Tektronix  if  user  gets  a  Macintosh  2. 

While  this  project  is  still  in  its  startup  phase  and  some  minor  problems  still  remain  to 
be  resolved,  we  are  extremely  high  on  the  Mac  and  VersaTerm  combination.  If  you  don't 
already  have  a  Mac  you  should  run  right  out  and  get  at  least  one. 


ISM  DECISION  TREE 


The  process  of  permit  review  obviously  Includes  more  than  a  geographic  analysis  of 
the  permit  area  as  performed  by  the  automated  routine.  Each  permit  application  must  be 
evaluated  with  regard  to  a  set  of  guidelines  related  to  environmental  considerations. 
These  guidelines  are  grouped  according  to  feature,  and  one  or  more  groups  must  be 
considered  for  each  permit.  There  are  approximately  twelve  guidelines  per  group. 

Review  of  the  guidelines  can  be  tedious,  and  an  opportunity  to  make  this  process 
more  efficient  and  uniform  was  explored.  The  primary  goal  was  to  assess  the  guidelines 
with  regard  to  their  relationship  with  one  another  based  on  the  possibility  that  compliance 
with  a  specific  guideline  would  automatically  satisfy  compliance  with  one  or  more  other 
guidelines.  This  relationship  among  the  guidelines  allows  a  decision  tree  to  be 
constructed  such  that  a  review  of  the  guidelines  in  a  structured  order  would  reduce  the 
necessity  of  reviewing  all  the  guidelines  since  some  are  in  the  domain  of  others. 

With  a  team  from  CMD,  a  computer  technique  termed  Interpretive  Structural 
Modeling  (ISM)  was  used  to  develop  a  guideline  decision  tree  for  the  various  sets.  ISM  is 
a  group  decision  making  process  which  allows  the  group  to  define  the  pattern  of  relation 
among  a  set  of  elements  and  express  this  pattern  in  a  hierarchical  graph  format.  This  is 
accomplished  with  a  series  of  comparisons  and  the  use  of  inference  which  reduces  the 
number  of  actual  comparisons  needed  to  define  the  structure.  The  resultant  trees  were 
translated  to  tables  and  saved  in  computer  files.    A  program  was  written  to  follow  the 
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tables  and  present  the  guidelines  for  review  to  the  analysts  based  on  their  response  to 
the  permit's  compliance. 

There  are  plans  to  ultimately  link  the  Decision  Tree  to  the  APAS.  When  a  guideline 
calls  for  reference  to  map  or  environmental  data,  this  request  could  be  passed  to  the 
APAS  where  the  analysis  could  be  performed  automatically  and  the  results  presented  to 
the  analyst. 

Quantification  via  the  decision  tree  can  be  taken  a  step  further.  Since  the  importance 
of  each  guideline  is  known,  they  can  be  weighted  and  the  reviewer  will  be  able  to 
respond  with  the  level  of  compliance  of  the  permit  to  each  guideline  based  on  a  scale 
(0-4).  Scores  will  then  be  derived  for  each  permit  based  on  the  guideline  weights  and  on 
the  permit's  overall  degree  of  compliance  with  all  guidelines.  This  will  provide  the  analyst 
with  additional  means  to  quantify  permit  evaluation. 

This  program  provides  several  additional  benefits  including: 

0  A  standard  and  consistent  methodology  for  reviewing  permits; 

0  An  efficient  method  of  determining  the  relevant  guidelines; 

0  A  printed  copy  of  the  guidelines  which  apply; 

0  Speeding  up  of  the  analysis. 

An  aspect  common  to  many  of  the  above  procedures  is  the  printing  of  hardcopy 
output.  This  information  can  be  very  effectively  used  in  several  ways: 

0  Included  in  the  permit  file  for  documentation; 

0  A  convenient  source  of  information  for  further  investigation; 

0  Sent  to  the  user  along  with  the  usual  CMD  response. 

We  feel  that  the  value  of  the  last  use  is  an  often  overlooked  benefit  of  these  types  of 
programs  in  that  the  computer  output: 

0  Helps  to  make  the  requestor  aware  of  the  thought  and  work  that  went 

into  making  permit  decisions; 
0  Helps  to  make  the  requestor  aware  of  the  amount  of  work  that  was  devoted 

to  THEIR  permit; 
0  Helps  to  quantify  rather  than  just  qualify  the  analysis  to  the  requestor; 
0  Sometimes  emphasizes  the  importance  of  the  information  presented 

more  than  typed  material. 
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DECISION  ASOCIATES,INC.    00    MAP  INDEX  PROGRAM  OUTPUT 


DECISION  ASSOCIATES,  INC.     MAP  INDEX  SYSTEM  FOR  CMD  09-09-86       run    9-1 9-86       1 6:02:1 6 

STREIFFER  permit  P860530         lat  29-24-50    (29.4139)  long  90-12-39    (90.2108) 

UTMZONE:  15         NORTHING:  3256901 .47         EASTING:  770636.46 


7.5  MIN  QUAD:   243A        NAME: GOLDEN  MEADOW  FARMS  MONIKER: GLDMF 

SCALE  1:24000  INTERVAL:  1"=   2000.0ft,       609.6m,      .610km 


ADJACENT  MAPS:      GROUND  DISTANCE  TO  BOUNDARY 
244B   WEST  2.35mi     =     3.77km 

244D   SOUTHWEST  3.56ml     =     5.73km 

243C   SOUTH  2.68mi     =     4.31km 


SOURCE 

CMD# 

NAME 

H/C  MAP 

243A 

TOPOGRAPHIC 

H/C  MAP 

243A 

1956    N.W.I.  HABITAT  MAP 

H/C  MAP 

243A 

1978    N.W.I.  HABITAT  MAP 

H/C  MAP 

243A 

OYSTER  LEASE  MAP 

05 


MAP  DISTANCE  TO  BOUNDARY 

6.1 9in 

= 

157.3mm 

9.40in 

= 

238.7mm 

7.07in 
NTH 

s 

179.6mm 

YEAR              P.R. 

1956               1979 

1956 

1978 

1984 

NAV  CHART   :    1341         NAME  :  LITTLE  LAKE  MONIKER: 

SCALE  1:    8000  INTERVAL:  1"=  6666.7ft,     2032.0m,     2.032km 


ADJACENT  MAPS: 
SOUTH 
SOUTHEAST 
EAST 

SOURCE      CMD  # 
H/C  MAP  ;  1341 


GROUND  DISTANCE  TO  BOUNDARY 
1.03mi    "     1.66km 
14.12mi     =  22.72km 
14.08ml    =  22.66km 

NAME 
NAVCHARTC 


MAP  DISTANCE  TO  BOUNDARY 

.82in     = 

20.8mm 

11.18in     = 

284.0mm 

11.15in     = 

283.3mm 

MONTH 

YEAR              P 

12 

1984 

LANDSAT   DATA:    permit  is  SOUTHEAST  OF  APPROX.   CENTER   OF   29.5230  ,  90.2713 
name  :  LEEVILLE  &  LITTLE  LAKE  date  :  12  021984  cmd#:0007 

id  =  Y502761 6022X0  quad  =  1  pattn  =  22  row  =  40  dg  tape  143 


PHOTOGRAPH  SERIES  NASA85         SEARCH  RADIUS  =  19.59  mi 
SCALE  1:65000         INTERVAL:  1"=  541 6.7ft,      1651.0m,     1.651km 

CMD#  ROLL      PRAM   MM  YEAR     SCALE    LATITUDE        LONGiTUD     TY    F       SERIES      DISTANCE 


03549 

1347 

1985 

65000 

29.3839 

90.2217 

IR 

N 

NASA85 

2.17 

03549 

1346 

1985 

65000 

29.3819 

90.1697 

IR 

N 

NASA85 

3.30 

03549 

1348 

1985 

65000 

29.3797 

90.2747 

IR 

N 

NASA85 

4.49 

03549 

1212 

1985 

65000 

29.4839 

90.2208 

IR 

N 

NASA85 

4.86 

03549 

1211 

1985 

65000 

29.4842 

90.1697 

IR 

N 

NASA85 

5.43 

03549 

1213 

1985 

65000 

29.4872 

90.2683 

IR 

N 

NASA85 

6.11 

03549 

1345 

1985 

65000 

29.3825 

90.1131 

IR 

N 

NASA85 

6.24 

03549 

1210 

1985 

65000 

29.4842 

90.1172 

IR 

N 

NASA85 

7.41 

03549 

1349 

1985 

65000 

29.3770 

90.3272 

IR 

N 

NASA85 

7.42 
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AREA  SUMMARY  FOR  1 956  IMPACT  CIRCLE         ACTIVE  MAP  NO. 
SUBJECT  AREA       FREQUENCY     PERCENT 


E10W0. 

PEM. 

USS13S. 


11.14 

1 

2.22 

461.75 

2 

91.97 

29.19 

2 

5.81 

TOTAL  (IN  ACRE 

S) 

502.1                          5         100.00 

AREA  SUMMARY 
SUBJECT 

FOR  1 978  IMPACT  CIRCLE      ACTIVE  MAP  NO.      5 
AREA       FREQUENCY     PERCENT 

E1AB2. 
E10W0. 
E2EM5P5. 
USS1S. 

401.11                       4           79.89 
36.04                       2              7.18 
24.21                       4             4.82 
40.70                       4             8.11 

TOTAL  (IN  ACRES) 


502.1 


14         100.00 
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AREA  CHANGE 

S  FOR  1956  TO  1978  HABITATS 

ID        VALUE 

AREA 

-REQUENCY 

% 

56-SUBJECT--78 

1             2.1000 

392.85 

15898.0 

78.27 

PEM. 

E1AB2. 

2            2.3000 

24.02 

972.0 

4.79 

PEM. 

E2EM5P5. 

3            2.4000 

28.34 

1147.0 

5.65 

PEM. 

USS1S. 

4            3.4000 

8.99 

364.0 

1.79 

USS13S. 

USS1S. 

5            3.1000 

9.02 

365.0 

1.80 

USS13S. 

E1AB2. 

6            1 .4000 

2.74 

111.0 

.55 

E10W0. 

USS1S. 

7            1.2000 

8.45 

342.0 

1.68 

E10W0. 

E10W0. 

8            3.2000 

10.97 

444.0 

2.19 

USS13S. 

E10W0. 

9            2.2000 

16.56 

670.0 

3.30 

PEM. 

E10W0. 

TOTAL  ACRES 

501.9 

20313.0 

78.37 

(  138.6  ACRES  BACKGROUND) 

AREA  SUMMARY  FOR  ECO  ATLAS  ACTIVE  MAP  NO.     1 2 


SUBJECT  AREA       FREQUENCY  PERCENT 

H20F0WLC  422.29                      1  92.03 

SENSITIV  36.56                      1  7.97 

TOTAL  (IN  ACRES)  458.8                       f  100.00 


SUMMARY  FOR  MAP  TER86PTMAP  PERMIT  LOCATIONS 


I.D.  CUPNO  NAME  ACKNOWL      PARISH       ST  PERMTYPE 

555  P851438  CIMARRON  851105       LAFOURCHE     4  110  0  0  10 

560  P821301  DAVISOIL  820902       LAFOURCHE     4  11099  0  00 

569  P851189  SOUTHPORT  850911        LAFOURCHE     4  11 


IDTOMRTED  PERMIT  INiLf  SIS  SYSTEM  eilTPDT 


I 
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1956  IMPACT  CIRCLE 
^ 


' — — / 

V                                                                                                                                                         / 

/ 

^ 

\ 

/ 

■-. 

/ 

s 

y 

y 

^ 

y 

■mOMBTED  PERMIT  RNRLTSIS  SYSTEM  IBTPBT 


DECISION  ASSOCIATES  AUTO  PTS 


19-SEP-8G 
REUIEUER 
PERniT  t 
LAT  LON  CORD 

urn  COORD. 

PROXiniTY    ! 
HABITAT  MAP 
PERMIT  HAP 
ATLAS  HAP 


STREIFFER 
P86053e 

ag-a^-se  99-12-39 

778636.5  3356981.5 

e.5 

GLDriF78HAB 
TERSePTHAP 
TER8inERG3 


1878  IMPACT  CIRCLE 
WITH    PERbllTS 


Wa 


•// 


^^x^' 

N-m 

III 

1    1< 

WATEK 

FRESH  MARSH 

INTERMEDIATE  MARSH 

BRACKISH  MARSH 

SAUNE  MARSH 

NON-FRESH  MARSH 

UPLAND  FOREST 

BOTTOMLAND  HARDWOODS 

SWAMP 

SHRUB/SCRUB 

AG/PASTURE 

DE\-ELOPED 

AQUATIC  VEGETATION 

INERT 

UNASSIGNED 


HABITAT 
SHADE 
PA  TTERNS 


ENVIRONMENTAL  SENSITIVE  AREAS  SHADED 


(821381 
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THE  IMPLEMENTATION  OF  A  REGIONAL  ATLAS  TO  SUPPORT  THE  LONG  TERM  MONITORING 
REQUIREKEBTS  OF  THE  NATIONAL  ACID  PRECIPITATION  ASSESSMENT  PROGRAM 

By: 

William  Gierke,  Charles  Dull,  Robert  Dhler,  and  H.  Danial  Brown 
DSDA  Forest  Service,  Southern  Region,  Atlanta  Ga. 


ABSTRACT 

The  National  Acid  Precipitation  Assessment  Program  is  a  multi-agency  effort  of 
the  federal  government  established  to  determine  the  adverse  affects  of  acid 
precipitation  and  related  atmospheric  pollutants  on  the  ecosystem.  One  task  of 
this  effort  is  to  develop  and  implement  a  long  term  monitoring  system  to  assess 
the  affects  of  these  pollutants  on  the  nation's  forests.   It  was  the  consensus 
of  opinion  among  key  scientists  from  across  the  country  that  information 
concerning  the  location  of  areas  of  forest  vegetation  potentially  stressed  by 
either  pollutant  induced  or  natural  processes  was  essential  for  developing  the 
stratification  and  sampling  scheme  necessciry  to  implement  the  long  term 
monitoring  system.   It  was  decided  that  an  interactive  "atlas"  containing 
spatial  information  which  permits  investigators  to  locate  forest  areas  where 
stress  is  likely  to  occur  was  essential  for  meeting  the  program  objective. 
Originally,  the  system  was  envisioned  as  a  dynamic  electronic  atlas  operating 
on  microcomputers  at  individual  research  locations,  with  results  shared  among 
investigators . 

Initially,  the  atlas  concept  is  being  implemented  by  the  USDA  Forest  Service, 
Southern  Region,  Forest  Pest  Management  Staff  Unit,  on  a  dedicated  Data  General 
MV  4000  minicomputer  using  the  MOSS  family  of  software  products.  The  thirteen 
southeastern  states  are  the  initial  geographic  extent  of  the  atlas.  Weather, 
timber,  soils,  and  atmospheric  deposition  have  been  identified  as  the  four 
primary  data  themes  necessary  to  implement  the  atlas  concept.  Assembling  the 
data  from  these  diverse  data  themes  has  required  ingenuity  and  the  development 
of  specialized  data  manipulation  software.  The  weather  data  for  the  atlas  will 
include  data  from  more  than  100  airways  weather  stations  spanning  a  time  period 
of  30  years.  Initial  atmospheric  pollutant  data  covers  a  5-year  period,  from 
1980  through  1985.  Data  in  these  two  data  themes  are  tabular  records  linked  to 
station  coordinate  locations.  County  estimates  of  growing  stock  volume  and 
type  acreage  provide  the  forest  location  data.  The  soils  data,  digitized  from 
state  generalized  soils  maps,  was  included  to  support  the  assessment  of  forest 
stress.  Available  moisture  capacity  to  a  depth  of  40  inches  is  the  first 
stress  related  soil  variable.   Initial  data  loading  and  entry  has  been 
completed  for  timber,  atmospheric,  and  soil  data  themes.  Because  of  the  large 
volume  of  data  entry,  the  weather  data  is  still  in  progress. 

The  project  represents  a  unique  approach  to  multidisciplinary  research  and 
presents  the  first  exposure  of  a  wide  spectrum  of  research  scientists  to 
geographic  information  system  technology  and  the  MOSS  family  of  software 
products. 


INTRODDCTION 

Throughout  geologic  time  plants  and  animals  have  acted  to  modify  the  earth's 
environment  and  atmosphere.  Until  recently  these  changes  occurred  slowly  over 
the  span  of  thousands  of  years.  Over  the  last  two  centuries »  however,  human 
activities  have  altered  the  earth's  chemistry  in  ways  which  may  cause 
staggering  ecological  and  economic  consequences.  The  National  Aid 
Precipitation  Assessment  Program  (NAPAF)  was  established  in  1980  under  the 
statutory  authority  of  Title  ¥11  of  the  Energy  Security  Act  (PL  96-294).   "The 
goal  of  the  National  Acid  Precipitation  Assessment  Program  is  to  develop  a 
comprehensive  information  base  on  the  causes  and  effects  of  acidic  deposition 
and  to  provide  methods  for  effective  management  of  the  problem." 

The  Forest  Response  Program  was  established  under  the  NAPAP  (terrestrial 
effects)  Task  Group  to  answer  three  broad  policy  questions. 

1.  Is  there  a  significant  problem  of  forest  damage  in  North  America  which 
might  be  caused  by  acidic  deposition,  alone  or  in  combination  with  other 
pollutants  (e.g.,  SO  ,  NO  ,  0_,  H+,  metals,  H_0  ,  or 

hydrocarbons)? 

2.  Mhat  is  the  causal  relationship  between  acidic  deposition,  alone  or  in 
combination  with  other  pollutants,  and  forest  damage  in  North  America? 

3.  ¥hat  is  the  dose-response  relationship  between  acidic  deposition,  alone 
or  in  combination  with  other  pollutants,  and  forest  damage  in  Horth  America? 

Each  of  these  broad  policy  questions  has  been  translated  into  a  set  of 
scientific  questions.  The  National  fegetation  Survey  Program  Support  Atlas  is 
being  implemented  to  serve  as  a  tool  for  answering  scientific  questions  posed 
for  policy  issue. 

1.  Are  changes  in  forest  conditions  greater  than  can  be  attributed  to 
typiced  trends  and  levels  of  natural  variability? 

2.  What  spatial  patterns,  if  any,  exist  in  forest  conditions,  and  how  do 
these  patterns  relate  to  the  spatial  patterns  of  pollutant  exposure? 

0BJECTI7E 

Our  objective  in  implementing  the  National  Vegetation  Survey  Program  Support 
Atlas  is  to  provide  program  management  smd  investigators  with  the  spatial  data 
and  analysis  capabilities  necesseipy  to  support  the  definition,  implementation, 
conduct,  documentation,  and  reporting  of  activities  conducted  to  determine  the 
impact  of  atmospheric  deposition  and  other  stress  factors  on  the  growth  and 
yield  of  southern  commercial  forests.  The  term  atlas,  i„e.,  a  collection  of 
maps,  does  not  clearly  describe  the  guiding  concept  of  this  effort.  The 
scientists  who  developed  the  project  believed  that  an  understanding  of  the 
interrelationship  among  stress  factors  and  the  location  and  physiological 
condition  of  the  forest  was  essential  for  meeting  program  objectives.  They 
envisioned  a  capability  to  perform  spatial  display  and  analysis  of  variables 
related  to  stress  factors  and  tree  physiology  that  would  provide  an 
understanding  of  the  interrelationship  between  these  data  elements.  This 
capability  could  then  guide  the  development  of  sampling  strategies  for 
objectively  quantifying  the  impact  of  atmospheric  deposition  and  other  stress 
factors  on  the  forest.  To  be  effective,  the  Program  Support  Atlas  must  be 
available  to  a  wide  range  of  investigators.  The  data  base  nmst  be  updated  as 
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new  information  becomes  available.  As  new  hypothesis  are  advanced i  additional 
spatial  ancilysis  models  must  be  implemented.  Personal  computers  have  been 
targeted  for  eventual  distribution  of  the  Program  Support  Atlas  software  emd 
data.  The  implementation  of  the  Program  Support  Atlas  is  a  challenge  to  both 
computer  technology  and  our  capability  to  conduct  effective  interdisciplinary 
research. 

SELECTION  OF  PROCESSING  SYSTEM  TECHKOLOGI 

Three  basic  classes  of  computer  systems  capable  of  manipulating  spatial 
geographic  information  were  considered  for  implementing  the  atlas  project. 

Computer  aided  mapping  (CAM)  systems  sire  intended  for  the  development  and 
updating  of  printed  maps.  These  systems  have  special  capabilities  for  placing 
the  type  and  symbols  common  on  printed  maps.  They  do  not,  however,  recognize 
line  segments  as  components  of  spatial  entities,  nor  do  they  posses  the 
computational  capability  necessary  to  implement  the  Program  Support  Atlas. 

The  second  class  of  systems  could  be  generally  described  as  map  display 
systems.   In  these  systems,  a  series  of  attributes  or  variables  are  linked  to  a 
geographic  entity.  Population  and  median  income,  for  example,  might  be  linked 
to  a  series  of  coordinate  values  that  describe  county  boundaries. 

The  third  class  of  systems.  Geographic  Information  Systems  (GIS),  have  a  data 
structure  similar  to  map  display  systems.  The  primary  difference  between  the 
two  classes  of  systems  is  in  the  extent  of  their  analytical  capability.  A  map 
display  system  is  limited  to  numeric  and  logical  calculations  on  the  attributes 
attached  to  each  geographic  entity.  A  GIS  is  capable  of  analyzing  both  the 
spatial  and  attribute  data.  Both  systems  could  display  all  counties  with  a 
population  of  over  100,000  and  a  median  income  of  over  ^10,000.  A  GIS  could, 
in  addition,  operate  on  the  cartographic  entities  and  determine,  for  example, 
the  distance  of  these  counties  from  interstate  highways.  Because  GIS  systems 
can  operate  on  spatial  data,  they  are  capable  of  analyzing  data  from  more  than 
one  data  theme  simultaneously.  They  can  answer  questions  such  as:  where  are 
counties  with  over  100,000  cubic  feet  of  loblolly  timber  per  acre  that 
experienced  excessively  low  spring  rainfall  in  1985  located.  GIS  technology 
was  chosen  to  support  the  implementation  of  the  Program  Support  Atlas  because 
of  its  capability  to  both  analyze  spatial  data  and  tabular  variables. 

The  Map  Overlay  and  Statistical  System  (MOSS),  a  public  domain  GIS  operating  on 
a  dedicated  Data  General  MV  llOOO  minicomputer  operated  by  the  USDA  Forest 
Service,  Southern  Region,  Forest  Pest  Management  Staff  Unit,  was  selected  for 
initial  implementation  of  the  Program  Support  Atlas.  The  system  includes  two 
digitizing  stations  with  graphic  terminals,  a  color  graphic  display  station,  an 
image  display  station,  and  text  terminals.  An  eight-pen  ploter  provides  map 
output  products.  The  system  includes  592  megabytes  of  fixed,  and  192  megabytes 
of  removable  disk  storage  capacity,  along  with  a  high  density  tape  drive. 

PRIMARY  DATA  DIVISIONS 

A  fflultldisciplinary  panel  of  scientists  initially  identified  four  primary  data 
divisions  necessary  to  meet  the  objectives  of  the  project. 

(1)  Weather 

(2)  Soils 

(3)  Atmospheric  Deposition 

(4)  Timber 

In  addition,  it  was  decided  to  initially  limit  geographic  coverage  to  that 
portion  of  the  thirteen  southern  states  extending  south  from  Virginia, 


Kentucky*  and  Teimessee>  west  to  Texas  and  Oklahoma,  and  east  of  the  100th 
meridian.  Assembling  the  data  for  each  of  the  data  divisions  has  been  a 
significant  task.  The  data  for  each  atlas  data  division  have  been  prepared  by 
investigators  with  the  discipline,  specific  knowledge,  skills,  and  capabilities 
necessary  to  assemble  the  required  data.  The  following  sections  were  extracted 
from  descriptions  prepared  by  the  scientists  responsible  for  assembling  the 
data  for  a  recent  program  review.  These  scientists  were  responsible  for  the 
data  for  the  atlas  data  divisions: 


DATA  DIVISION 


INVESTIGATORS 


AFFILIATIONS 


WEATHER 


Dr.  James  Paul 
Ken  Forbus 


DSDA  Forest  Service 
Southeastern  Forest 
Experiment  Station 

Hacon,  Georgia 


Soils 


Dr.  J.  R.  Jorgensen 
Kin  Ludovici 


DSDA  Forest  Service 
Southeastern  Forest 
Experiment  Station 
Research  Triangle  Park 
North  Carolina 


Timber 


Dr.  Roy  Beltz 


DSDA  Forest  Service 
Southern  Forest  Experiment 
Station,  Starkville,  Miss. 


Joseph  McClure 


Southeastern  Forest 
Experiment  Station 
Asheville,  North  Carolina 


Atmospheric  Deposition   Dr.  Al  Lefohn 


ASl  Associates 
Helena,  Montana 


Dr.  Rudolf  Husar 


Trend  Analysis  Group 
Clayton,  Missouri 


Weather 


Tree  growth  is  the  result  of  complex  integrations  among  many  physical, 
chemical,  and  biological  processes.  Weather  is  the  major  and  most 
uncontrollable  factor  influencing  tree  growth.  Dnfortunately,  there  is  no 
definitive  model  that  uses  weather  to  predict  tree  growth.   In  the  absence  of  a 
weather-driven  tree  growth  model,  it  was  necessary  to  identify  from  the 
literature  the  weather  variables  and  their  averaging  periods  for  use  in  the 
atlas.  Furthermore,  since  trees  have  evolved  over  the  years  in  response  to 
weather,  then  it  seemed  logical  to  describe  the  weather  variables  as  deviations 
from  the  long-term  average.  It  should  be  noted  that  this  undertaking  far 
exceeds  any  previous  attempt  in  the  Dnited  States  to  define  and  summarize 
weather  in  this  fashion  over  such  a  large  area  (530  million  acres). 


Weather  variables  and  soiu'ces  being  included  in  this  atlas  are: 

1.  Dry-bulb  temperature   (maziiouB  and  miniitiuin) 

2.  Precipitation 

3.  Relative  humidity 

4.  Cloud-cover 

5.  Devpoint  temperature 

6.  Wind  direction 

7.  Wind  speed 

8.  Vector  wind  average 

9.  Visibility  (fog,  smoke,  etc.) 

10.  Turner  stability  class  (i.e.,  atmospheric  stability) 

Each  variable  will  be  represented  as  monthly  averages  and  deviations  from  the 
10,  20,  or  30  year  average.  The  source  for  all  input  data  for  all  variables  is 
the  National  Climatic  Data  Center  in  Asheville,  North  Carolina.  Hourly  surface 
observation,  summary  of  the  day,  and  hourly  rainfall  data  were  obtained  from 
the  available  stations  in  the  region.  The  hourly  surface  data  (airways) 
require  extensive  decoding  and  reformatting.  For  example,  the  decoding  of  one 
airways  station  for  the  period  19^5-1983  requires  about  4  hours  on  an  IBM 
370-148. 

Airways  data  is  surface  weather  collected  hourly  at  airports.  Data  from  120 
such  stations  will  be  decoded  and  analyzed.  Data  to  be  electronically  stored 
include  the  raw  sums,  cross  products,  and  frequency  information  by  hour,  month, 
and  yceir.  Hourly  rainfall  data  will  be  obtained  from  the  airways  data  set  and 
from  over  840  other  rainfall-measuring  stations  in  the  region. 

Soil 

Next  to  distribution  and  amount  of  rainfall,  the  capacity  of  soil  to  hold  and 
gradually  provide  sufficient  moisture  is  most  important  for  tree  growth. 
Available  moisture  capacity  (AMC)  of  soil  depends  primarily  on  texture,  organic 
content,  depth  of  each  horizon,  and  volume  of  soil  available  to  tree  roots. 
Available  moisture  generally  increases  with  organic  matter  content  and,  to  a 
point,  with  a  decrease  in  particle  size.  Clays  may  have  a  high  total 
moisturfe-holding  capacity,  but  only  moderate  AMC.  Furthermore,  density  and 
structure  of  some  silty  and  clayey  soils  restrict  root  growth  and  prevent 
complete  utilization  of  available  soil  moisture.  Similar  restrictions  to  root 
growth,  such  as  pans  and  other  compact  layers,  water  tables,  and  rocks,  can 
reduce  the  effective  rooting  volume  from  which  moisture  can  be  obtained. 

Acidic  deposition  may  eilso  affect  productivity  of  certain  soils  in  the  South. 
Certain  soil  characteristics  can  be  used  to  predict  a  soil's  sensitivity  to 
acid  deposition.  Soil  sensitivity  to  these  stresses  should  be  assessed  and  put 
in  atlas  format.  Soil  parameters  chosen  for  the  sensitivity  interpretation 
were  AMC,  surface  ph,  ph  at  40  inches,  percent  organic  matter,  percent  clay  at 
the  surface,  and  percent  clay  at  25  inches. 

Data  source:  General  soil  maps  were  obtained  from  the  Soil  Conservation  Service 
for  each  state  in  the  South.  Data  on  the  selected  soil  parameters  were 
gathered  with  the  assistance  of  the  Soil  Information  System  (SIS),  a  division 


of  the  Environmental  Technical  Information  System  (Dniversity  of  Illinois, 
Drbana) , 

State  soil  maps  are  typically  divided  into  Multiple  Land  Use  Areas  which  are 
further  divided  into  Soil  Associations.  Soil  Associations  contain  from  one  to 
four  individual  soil  series  with  the  listed  soil  series  making  up  at  least  70S 
of  the  Association.  Calculations  began  with  the  smaller  soil  groups. 

Equations  for  final  calculations  of  Soil  Associations  were  based  on  the  range 
for  each  individual  soil  series  and  on  the  proportion  of  that  series  in  the 
Association. 

Timber 

Forest  surveys  have  been  conducted  periodically  by  Forest  Inventory  Analysis 
(FIA)  units  in  the  DSDA  Forest  Service  since  the  passage  of  the  McSweeny-McNary 
Act  in  1928.  Subsequent  legislation  has  expanded  the  role  of  the  Forest  Survey 
but  its  basic  mission  remains  and  its  data  sets  are  the  most  consistent  and 
contribute  the  most  detailed  descriptions  of  forest  resources  in  the  United 
States.  To  coordinate  the  use  of  the  various  atlases,  it  is  imperative  that 
the  geographic  location  and  frequency  (growing  stock  cubic  volume  and  forest 
area)  of  the  important  tree  species  and  forest  types  in  the  southern  region  be 
displayed, 

FIA  units  from  the  Northeastern,  Southeastern,  and  Southern  Forest  Experiment 
Stations  supplied  county  data  for  this  atlas.  All  the  definitions  and 
procedures  used  by  the  various  FIA  units  involved  are  closely  aligned  to  assure 
compatible  resource  estimates.   Since  surveys  are  conducted  continuously  in  the 
Souths  and  in  a  cyclical  fashion,  the  dates  of  the  surveys  vary  by  state.  In 
each  state,  the  most  recent  survey  data  will  be  depicted.  The  date  of  survey 
will  be  shown  for  each  state.  As  new  surveys  are  completed,  new  information 
will  become  available  for  incorporation  into  the  atlas. 

Surveys  were  originally  designed  to  provide  reliable  estimates  of  forest  area 
and  volume  at  the  state  level.  The  data  are  commonly  used  for  smaller  areas 
but  reliability  falls  off  rapidly  as  the  focus  of  interest  narrows.  Individual 
county  estimates  are  subject  to  sampling  errors  of  about  3%   for  area  and  ^5  % 
for  volume.  Smaller  counties,  counties  with  little  forest  area,  or  highly 
variable  conditions  due  to  topography,  etc.,  will  have  even  larger  sampling 
errors.  County  estimates  are  useful,  however,  for  accumulating  estimates  for 
larger  areas  and  for  displaying  geographic  distributions  of  various  forest 
resource  parameters. 

Data  sets  with  county  value  can  be  used  to  show  the  distributions  and  the 
relative  frequencies  of  occurrence  of  the  most  important  species  in  the 
region.  The  atlas  will  show  growing  stock  volume  for  the  major  commercial 
timber  species  and  areas  for  the  major  forest  types  in  the  South. 

Atmospheric  deposition 

Air  quality,  wet  deposition,  and  haze  data  for  the  South  were  obtained  and 
characterized  from  all  primary  data  sources:  (1)  United  States  Environmental 
Protection  Agency  (SAROAD),  (2)  Electric  Power  Research  Institute  (SURE  and 
ERAQS),  (3)  Tennessee  Valley  Authority,  and,  (4)  National  Park  Service.  Prior 


to  characterizing  the  ozone,  sulfur  dioxide,  and  nitrogen  dioxide  hourly  mean 
concentrations,  the  DSDA  Forest  Service,  Southern  Region  Forest  Pest  Management 
Aerial  Survey  Team  (Atlanta,  Georgia)  obtained  aerial  photographs  of  the  640 
monitoring  sites  and  made  comprehensive  photo  interpretations  (2.5  mile  radius 
by  quadrant)  of  the  relevancy  of  the  sites  to  forest  areas.  Data  have 
initially  been  provided  for  a  site  subset  of  the  original  640  sites  based  on 
photo  interpretation  criteria. 

Monthly  characterizations  of  ozone  were  :  (1)  7-hr  average  (0900-1559);  (2) 
number  of  hours  that  make  up  the  7-hr  average  per  month;  (3)  number  of 
occurrences  >  0.06,  0.08,  0.10,  0.12,  0.14,  and  0.15  ppm;  and  (4)  number  of 
reported  hours  per  month.  Monthly  characterizations  of  sulfur  dioxide  and 
nitrogen  dioxide  data  were:  (1)  number  of  occurrences  ^0.01,  0.02,  0.03.  0.04, 
0.05,  0.06,  0.07f  and  0.08  ppm;  and,  (2)  number  of  reported  hours  per  month. 

For  characterizing  wetfall  deposition  and  concentration  in  the  region, 
precipitation  chemistry  data  were  obtained  from  (1)  the  National  Atmospheric 
Deposition  Program  (NADP),  (2)  the  Multistate  Power  Production  Pollution  Study 
(MAP  3S),  and,  (3)  the  Utility  Acid  Precipitation  Study  Program  (UAPSP).  A 
total  of  57  stations  cire  available  within  the  region. 

Wetfall  data  from  each  precipitation  chemistry  station  were  used  to  calculate 
monthly  and  annual  concentrations  and  deposition  of  sulfate,  nitrate,  calcium, 
hydrogen  ions,  and  ammonium.  The  deposition  information  was  reported  in 
oilliequivalents  per  square  meter/year.  Concentration  information  was  reported 
in  microequivalents/liter.  These  values  can  be  easily  converted  to  more 
meaningful  biological  values  such  as  kg/ha  and  mg/liter  of  rainfall, 
respectively.  Special  attention  was  given  to  the  procedures  of  data  handling 
for  records  that  contained  missing  data. 

Visibility,  or  visual  range  (kilometers),  is  the  furthest  distance  at  which  an 
object  can  be  discerned  by  the  human  eye.  Atmospheric  visibility  observations 
by  a  human  observer  are  made  at  all  major  meteorological  stations,  including 
airports.  Visibility  data  collected  at  meteorological  stations  have  severe 
limitations.  Prior  to  any  statistical  or  other  analysis,  it  is  essential  to 
scrutinize  and  make  the  appropriate  corrections.  The  extinction  coefficients 
are  calculated  from  values  of  visual  range  recorded  routinely  by  human 
observations  as  part  of  a  global  meteorological  network.  Eliminating  the  data 
during  rain,  snow,  or  fog,  and  performing  a  relative  humidity  correction,  one 
obtains  a  visibility  parameter  that  primarily  depends  on  man-made  haze. 
Long-term  trends  of  such  corrected  visibility  data  reflect  the  trend  of 
man-made  haziness.  It  is  more  convenient  to  show  the  trend  of  the  inverse  of 
visueil  range  or  haziness  rather  than  by  the  visual  (i.e.,  the  atmospheric 
extinction  coefficient)  range  itself.  The  extinction  coefficient  is  closely 
related  to  the  concentration  of  materials  in  the  air  that  cause  light 
scattering  and  absorption.  Hence,  the  coefficient  is  more  appropriate  than 
visual  range  for  use  in  trend  and  spatial  analysis.  Visibility  data  were 
obtained  from  44  monitoring  sites  in  the  South  over  the  period  1948-1983. 

ASSEMBLING  THE  DATA  BASE 

It  has  been  a  formidable  task  to  bring  together  the  diverse  data  in  the  four 
primary  data  divisions  into  a  common  structure  acceptable  for  GIS  analysis. 
Three  types  of  software  in  addition  to  the  standard  MOSS  utilities  were  used  in 


assembling  the  data  base:  (1)  AOS/VS  utility  software,  (2)  Genersilized  record 
manipulation  data  base  software  written  by  project  personal  (Record  Keeper), 
and,  (3)  specialized  task  specific  record  manipulation  software.  The  latter 
two  classes  of  software  were  written  in  BASIC. 

The  principal  challenge  in  preparation  of  the  attribute  data  arose  from  the 
lack  of  uniformity  in  input  materials.  Data  was  referenced  in  reports, 
provided  on  handwritten  code  sheets,  IBM  PC  diskettes,  and  computer  compatible 
tapes  in  both  ASCII  and  EBCDIC  character  sets.  In  some  cases,  the  "flat  files" 
were  actually  reports  written  to  disk  which  included  headers  that  had  to  be 
stripped  and  fields  that  did  not  line  up.  To  insure  uniformity,  we  requested 
the  use  of  standard,  two-character,  DS  Postal  Service  codes  for  state 
identification.  The  substitution  of  incorrect  postal  codes  by  some 
investigators  resulted  in  the  software  inserting  the  FIPS  code  for  the  Virgin 
Islands  (VI),  rather  than  Virginia  (VA)  in  the  data  record,  until  the  program 
was  modified.  Where  the  data  had  been  extracted  from  a  national  data  base,  the 
files  often  had  to  be  restructured. 

Our  approach  to  developing  multiple  attribute  or  ADDWAMS  point  files  from  data 
sets  provided  by  investigators  includes  five  steps. 

Step  1 .  Create  a  flat  file  using  data  set  specific  software.  Data  set 
specific  software  can  easily  be  developed  in  BASIC.   It  can  be  used  to  perform 
functions  not  easily  accomplished  with  Data  General  utilities  such  as 
Sort/Merge  or  SED.  The  software  also  documents  modifications  made  in  the  data 
set.  Examples  included  joining  physiccLL  records  so  that  each  logical  record 
exists  on  one  physical  record,  stripping  header  records  from  report  format 
data,  and  editing  state  identification  codes. 


the  Data  General  AOS/VS  environment.  The  data  in  Record  Keeper  data  bases  are 
stored  on  ASCII  flat  files.  Existing  flat  files  can  be  accessed  after  the 
field  structure  has  been  defined  using  the  Record  Keeper  data  base  definition 
function. 

Step  3.  Sort  subset  and  compute  additional  fields  using  Record  Keeper  to 
modify  the  initial  flat  file.  The  data  required  for  a  specific  map  generally 
represents  a  subset  of  the  data  provided  by  the  investigator.  A  weather  data 
set,  for  example,  consisted  of  records  with  fields  for  station  identification, 
station  location  (latitude,  longitude),  month,  year,  average  rainfall,  actual 
rainfall  and  deviation  from  the  average.  The  records  covered  the  period  from 
1980  to  1985.  We  were  asked  to  develop  a  map  showing  the  deviations  in  the 
spring  (March,  April,  May)  of  1981  rainfall  from  the  long  term  average.  In 
this  case  Record  Keeper  was  used  to  extract  records  for  the  relevant  months  and 
year,  sort  the  records  by  site  and  month,  and  compute  fields  for  total  spring 
rainfeill,  total  normal  rainfall,  mean  normal  rainfall,  and  the  difference 
between  actual  and  normal  spring  rainfall. 

Step  4.  Create  multiple  attribute  definition  and  data  files  and/or  ADDWAldS 
point  data  files  using  utility  programs  developed  on-site  using,  for  example, 
the  requirement  described  in  Step  3-   The  "create"  on  ADDWAHS  function  would  be 
used  to  create  a  file  in  standard  format.  The  user  has  the  option  of 
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Step  2.  Define  a  Record  Keeper  data  base  conforming  to  the  flat  file  data 
structure.  The  Record  Keeper  is  a  data  base  program  written  originally  for  the 
Apple  II  by  one  of  the  authors  (Dhler)  that  is  currently  being  rewritten  for      I 
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specifying  the  Record  Keeper  fields  to  be  included  in  the  subject.  The 
coordinate  values  in  the  Record  keeper  data  base  are  specified  by  location  and 
can  be  in  either  DDD:MM:SS  or  decimal  degree  format.  A  second  function  can  be 
used  to  automatically  create  a  MOSS  attributes  definition  file.  This  utility 
uses  the  formation  stored  in  the  Record  Keeper  data  base  definition  as  input  to 
create  the  MOSS  attribute  definition  file. 

Step  5.   Incorporate  the  data  into  the  MOSS  CIS  using  MOSS  ADD  and  utility 
attribute  commands.  Using  the  appropriate  commands,  data  prepared  using  the 
previously  described  procedures  can  be  added  to  a  MOSS  data  base. 

CURRENT  ACTIVITY 

Input  of  data  covering  the  Southern  Region  has  been  completed  for  the 
Atmospheric  and  Timber  data  division.  With  the  exception  of  Oklahoma,  where  no 
soils  map  suitable  for  digitizing  is  available,  the  soils  data  division  is 
complete.  Preparation  of  the  Weather  data  is  scheduled  for  completion  in  June, 
1987. 

A  three-state  subset  (Georgia.  North  Carolina,  and  South  Carolina)  of  the 
regional  data  base  is  being  used  to  develop  demonstration  maps  and  models. 
Twelve  maps  were  developed  for  a  recent  program  review.  Point  data  were 
interpalated  to  a  10,000  meter  grid  using  the  inverse  righted  distance  option 
of  the  MOSS  GRID  command.  We  anticipate  using  the  kriging  and  masking  options 
of  the  GRID  command  to  produce  maps  in  the  future. 

The  forest  Weather  and  Atmospheric  data  divisions  will  be  updated  annually. 
The  current  soil  data  derived  from  existing  generalized  state  soils  maps  will 
be  replaced  by  the  new  USDA  Soil  Conservation  Service  STATSGO  soil  geographic 
data  base  when  the  digital  data  has  been  released  and  interpretations  have  been 
completed.  We  anticipate  replacing  the  USDA  State  and  County  data  base  with 
the  USGS  1:2,000,000  digital  line  graphic  (DLG)  data.  Over  the  next  year  we 
will  add  a  data  division  that  will  present  the  distribution  of  major  forest 
pests  and  fire  disturbance. 

Assembling  the  data,  although  a  difficult  task,  is  only  the  first  step  in 
meeting  the  objectives  of  the  Atlas  Project.  Developing  GIS  analysis 
procedures  and  models  that  adequately  describe  the  distribution  of  pollutants 
and  the  physiological  status  of  the  forest  represents  the  next  major  challenge 
of  this  project. 
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ABSTRACT 

Image  processing  techniques  have  seen  increasing  popularity 
as  tools  for  deriving  useful  geographic  information.  This  trend 
will  continue  to  expand  as  image  processing  hardware  and  software 
become  less  expensive,  and  more  common  in  the  workplace. 
Designers  of  geographic  information  system  software  today  are  in 
a  position  to  incorporate  imagery  and  imagery  analysis  tools  into 
their  software  and  database  structures  if  they  so  choose. 
Systems  that  were  developed  without  image  processing 
considerations,  however,  can  be  difficult  to  re-design  to 
incorporate  the  new  data  models  and  image  processing  software. 
Although  the  MAPS  component  of  the  MOSS  family  can  import  raster 
data  from  a  remote  sensing  source,  MAPS  does  not  support  the 
exploitation  tools  that  allow  realtime  multi-channel  image 
analysis.  This  report  will  detail  an  example  of  successfully 
linking  AMS,  MOSS,  and  MAPS  to  an  existing  image  processor  with 
very  few  modifications  to  the  applications  software,  and  no 
changes  to  the  database  structure.  This  report  will  also  detail 
some  of  the  powerful  new  tools  that  resulted  from  combining  these 
two    technologies. 

INTRODUCTION 

The  MOSS  family  of  software  has  evolved  over  the  last  few 
years  into  a  very  capable  and  adaptable  geographic  tool.  MOSS, 
AMS,  MAPS,  and  some  of  the  other  members  of  this  family  can  be 
found  on  a  wide  variety  of  computers  servicing  an  even  wider 
variety  of  output  peripherals.  The  flexibility  and  adaptability 
of  the  MOSS  family  software  has  contributed  largely  to  its 
success  and  popularity. 

Image  processing  technology  blossomed  with  the  arrival  of 
low  cost  computing  hardware.  Recently,  the  proliferation  of  mini 
and  personal  sized  computer  based  image  processors  has  been 
staggering.  Relatively  low  cost  image  processing  has  now  become 
a  reality. 

Unfortunately,  the  MOSS  family  of  CIS  products  and  image 
processing  products  arose  independently,  such  that  neither  can 
currently  use  data  from  the  other  with  much  utility.  This  has 
been  true  for  many  CIS  packages  and  image  processing  packages, 
but  the  trend  now  is  to  design  integrated  systems  that  can  reap 
the  benefits  of  both.  Where  does  that  leave  the  MOSS  user 
community  who  want  imagery  considered  as  a  source  of  geographic 
capture  and  display?   This  was  a  question  we  asked  about  a  year 


ago  when  we  considered  how  we  could  get  AMS  and  MOSS  to  use  an 
image  processor. 

DESIGN  PHILOSOPHY 
The  first  inclination  was  to  re-design  the  databases  used  by 
AMS  and  MOSS  to  handle  multi-channel  raster  data.  Needless  to 
say,  this  would  have  involved  extensive  coding  and  cost.  Another 
approach  was  to  create  an  intermediate  format  that  could  be 
imported  or  exported  by  either  system.  The  problem  with  that 
approach  was  that  it  was  far  too  inefficient  in  that  data  was 
duplicated  excessively.  This  approach  also  suffered  from  the 
problem  that  it  rapidly  became  very  device  specific  -  one  of  the 
items  that  we  wanted  to  avoid  when  we  were  working  with  MOSS 
family  software. 

We  finally  came  up  with  the  idea  to  simply  build  and 
maintain  a  mathematical  link  between  the  two  systems,  and  to 
treat  the  image  processor  and  the  math  model  as  a  new  MOSS  family 
peripheral.  The  only  software  needed  was  that  to  establish  the 
math  model  and  apply  it  to  the  data.  Modifying  AMS  and  MOSS 
application  software  was  going  to  be  costly,  so  we  decided  to 
modify  a  section  of  the  "choke  point"  between  the  applications 
software  and  the  graphics  devices.  Figure  One  indicates  this. 
Some  of  the  advantages  to  this  approach  are  that  the  data  sets 
would  never  actually  have  to  meet,  applications  software  would 
not  be  heavily  altered,  the  approach  would  provide  a  "real  time" 
access  to  the  display  screen's  data  (versus  a  batch  approach), 
and  that  most  image  processing  packages  have  software  that  lets 
you  treat  the  display  like  a  graphics  peripheral. 

The  next  step  was  to  benchmark  some  potential  math  m.odels. 
We  selected  an  eight  parameter  polynomial,  as  it  was  the  most 
robust  of  the  models  tried,  and  the  easiest  to  use.  (It  does 
have  the  disadvantage,  however,  of  not  being  able  to  handle  cases 
where  terrain  relief  is  expressed  as  horizontal  shifts  in  the 
imagery.)  To  this  date,  the  technique  has  been  used 
successfully  on  Landsat  TM,  MSS,  digitized  airphoto,  and  Large 
Format  Camera  Imagery. 
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SOFTWARE  COMPONENTS 
This    section    of    the    paper    details    some    of    the    suggested    and 
potential   software   components   that   could   be  used   to  provide  an 
image  overlay  capability.      First,    the   basic  components   will   be 
addressed. 

There  are  only  two  basic  software  links  that  need  exist 
between  the  CIS  applications  software  and  the  image  processing 
software.  They  are:  a  read  screen  position  from  cursor,  and  a 
write  color  to  screen  position  capability.  With  these  two 
capabilities  a  generic  image  overlay  tool  can  be  developed.  The 
advantage  of  restricting  to  just  these  two  links  is  that  these 
represent  functions  that  can  be  found  on  almost  any  image  device 
and    its    controlling    software. 

The  more  complex  image  processing  systems  and  software, 
however,  usually  support  a  much  broader  range  of  image 
processing  and  control  options  to  the  programmer.  The 
temptations  to  allow  applications  software  to  access  these 
capabilities  must  be  checked  if  portability  of  the  software  is  a 
consideration.  One  way  of  preserving  these  two  simple  links  yet 
still  taking  advantage  of  some  of  the  other  features  of  the  image 
processor  is  to  add  the  additional  functionality  into  the  poll  or 
display  routines.  This  way,  the  applications  software  is  not 
disturbed.  An  example  of  this  technique  would  be  allowing  the 
trackbal 1/ joystick  to  scroll  or  roam  through  image  memory  when 
the  applications  software  calls  for  a  digitizer  input. 
Similarly,  trackball  buttons  could  be  exploited  during  a  poll 
sequence  to  indicate  conditions  (like  digitizer  mouse  buttons)  or 
to  toggle  items  such  as  channels  or  the  image  device's  zoom 
register.  The  disadvantage  of  this  approach  is  that  access  to 
zoom/scroll  and  other  embedded  functions  is  only  facilitated 
during  applications  software  digitizer  reads.  This  is  more  than 
made  up  for  by  the  fact  that  applications  software  will  not  have 
to  modified  to  control  zooming,  scrolling,  or  certain  toggling 
functions . 

If  one  were  to  relax  some  of  the  strict  portability  rules 
and  maybe  even  alter  small  portions  of  the  application  software, 
many  other  image  processing  related  tools  could  be  exploited  for 
use  in  the  CIS  imagery  overlay  environment.  These  functions  have 
particular    potential: 

•  Graphics   plane   erasure  •   3D   perspective  viewing 

•  Color    look  up   table   management       •  Hidden   line    removal 

•Screen  clear  •, Intrinsic    character   generators 

•  Screen    load  •  Hardware   warping 
•Flood    and    fill    of    polygons 

In  addition  to  the  image  processing/applications  interface 
software,  several  other  modules  prove  useful.  These  model 
management  utilities  include  model  generation  software,  model 
storagfe/retrieval  software,  model  test  and  evaluation  software, 
and   display   graphics    driver    model    control    software.       With   the 
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exception  of  the  last  module,  these  tools  should  reside  outside 
of  the  applications  software  area  as  denoted  on  Figure  One.  They 
should,  however,  be  made  available  from  a  main  menu  as  a  single 
options    or   as    a    set    of    options. 

The  model  generation  software  component's  task  is  to 
assemble  a  workable  mathematical  relationship  between  the  GIS's 
internal  reference  system  and  the  image's  coordinate  system. 
This  is  usually  effected  by  gathering  sets  of  coincident  points 
from  the  geographically  based  GIS  and  image  coordinates  (via 
screen  coordinates)  from  the  display  device.  In  the  case  of 
polynomial  solutions,  a  set  of  coefficients  is  then  solved  for. 
We  found  it  to  be  of  particular  benefit  to  the  operator  if  a 
normal  digitizer  registration  were  performed  on  a  map  mounted  on 
a  digitizing  table  next  to  the  image  display  screen.  This 
simplified  the  task  of  measuring  coincident  points  as  the 
operator  could  easily  match  a  feature  to  its  screen 
representation.  It  is  important  that  the  first  measurement  of 
each  set  come  from  the  image  screen,  as  if  there  are  any  cursor 
mobility  restrictions  caused  by  the  screen  being  a  grid  of  a 
fixed  number  of  measurement  points,  this  restriction  should  occur 
to  the  first  measurement  as  a  digitizer  affords  nearly  unlimited 
measurement  points.  Model  generation  software  should  be  flexible 
enough  to  allow  the  operator  to  manually  enter  geographic  or 
image  measurements  or  have  the  software  ingest  them  from  a  file. 
The  operator  should  also  be  able  to  indicate  choice  of  model  and 
to  view   the   mathematical   residuals   of   a    model    generation   attempt. 

Following  successful  model  generation,  software  should  be 
provided  to  store  accepted  coefficients  for  future  or  repeated 
use.       Model    retrieval    should   also   be   provided. 

Model  test  and  evaluation  software  is  also  very  useful,  and 
can  be  designed  to  be  a  very  diagnostic  package.  The  function  of 
the  model  test  and  evaluation  program  is  to  examine  the 
geographic  extent  of  a  model's  goodness  of  fit,  and  acceptability 
for  GIS  overlay  display  and  digitizing.  This  can  be  done  several 
ways.  Tabular  statistics,  graphic  depiction,  and  interactive 
polling   are   examples   of    useful    techniques. 

The  last  major  section  of  related  software  components  is  the 
display  graphics  driver  model  control  software.  This  set  of 
software  exists  in  the  device  driver  level  of  Figure  One  and  is 
responsible  for  routing  logic  flow  during  a  digitizer  poll  or 
display  call  to  the  image  processor  software  call  and  through  any 
set   of    model    coefficients. 

RESULTS: 
The  techniques  discussed  in  this  paper  were  fielded  on 
Autometric's  32  bit  VAX/VMS  version  of  AMS  and  MOSS.  The  image 
processor  used  was  a  Gould-DeAnza  FD5000  512x512  device 
controlled  by  Gould's  Minilips  library  of  image  processing 
software.  This  section  of  the  paper  details  some  of  the  exciting 
products   and   capabilities   that   resulted    from    the   mixture   of    these 


powerful  tools. 

The  products  and  capabilities  that  were  generated  when  the 
MOSS  family  components  were  mixed  with  an  image  processing  device 
fell  into  three  broad  categories:  masking,  exploitation,  and 
product  generation. 

Masking: 

When  MOSS   was  using  a   model   to  warp  output  graphics  over  a 

mediately   obvious    that   we    had    a    very 


could  be  useful  if  it  were  used  to  optimize  image  processing  by 
delineating  areas  of  interest.  An  example  of  this  could  be  the 
selection   of   all    areas    that   MOSS   knows    to    be    aircraft    parking 


military  aircraft  traffic.  Negative  masking  is  also  useful.  A 
negative  mask  shows  all  areas  not  to  consider.  An  example  of  a 
potential  use  of  this  technique  would  be  using  MOSS  to  mask  out 
all    land   areas    for   a    study   of   thermal    patterns    in   a    water   body. 

It  could  be  argued  that  correctly  classified  imagery  could 
also  perform  such  masking  functions.  In  many  cases  it  can,  but 
this  gets  more  and  more  difficult  as  the  limits  of  spectral 
classification  are  approached,  and  impossible  when  targets  are 
selected  that  have  little  of  no  imagery  manifestation  -  such  as 
political  boundaries,  cultural  attribution,  and  miany  subsurface 
items.  The  contextual  domain  is  especially  exciting  when  placed 
over  imagery.  When  proximity,  adjacency,  and  buffer  zone 
generation  within  MOSS  are  used  as  image  masks,  very  complex 
masks  can  be  generated  suitable  for  use  in  many  arenas.  In 
short,  moss's  complex  geographic  query,  combinatorial,  and 
synthesis  functions  can  be  used  to  guide  the  dissection  or 
concentrate    the   examination   of    images. 

Exploitation : 

The  GIS/imagery  overlay  and  capture  environment  described  in 
this  report  had  a  major  positive  effect  on  the  operator's  ability 
to  exploit  the  imagery.  Although  imagery  exploitation  was  mainly 
boosted  in  AMS,  MOSS  also  contributed.  The  increased  facility 
can  be  broken  down  into  two  areas  of  impact:  data  capture  and 
imagery    analysis. 

Data  capture  was  greatly  enhanced  by  having  the  imagery 
context  available  while  digitizing.  The  workstation  design 
included  the  ability  to  toggle  between  registered  devices,  in  our 
case,  a  table  digitizer  with  a  mounted  map  and  the  image  display 
tube.  This  arrangement  allowed  for  the  best  of  both  products  to 
be  exploited.  Features  such  as  political  boundaries  and  precise 
road  centerlines  could  be  digitized  off  the  map,  then  imagery 
dominant   features    like   vegetation   and   thermal    plumes   could   be 


captured  off  the  screen.  Data  capture  was  further  enhanced  by 
having  a  common  capture  and  display  surface.  By  displaying  the 
contents  of  the  GIS  database  onto  the  image  display  tube  prior  to 
and  during  the  digitizing  process  it  was  immediately  obvious  to 
the  operator  what  had  and  hadn't  been  collected  yet. 
Furthermore,  revisiting  previously  capture  items  such  as  nodes 
became  very  easy  because  the  graphic  representation  of  that  node 
was  on  the  digitizing  surface.  One  final  enhancement  to  data 
capture  was  the  ability  to  have  softcopy  processes  flag  areas 
that  the  operator  might  want  to  examine  to  update  the  GIS 
database.  An  example  might  be  a  softcopy  change  detection 
algorithm  alerting  a  digitizer  operator  to  a  change  that  it  felt 
was  important.  If  the  digitizer  was  an  analytical  stereoplotter, 
the  stages  could  be  driven  to  the  points  of  interest  for  closer 
examination. 

Just  as  data  capture  was  enhanced  by  the  GIS/imagery 
juxtaposition,  so  was  image  analysis.  The  immediate  benefit  was 
the  ability  to  identify  features  on  the  image  by  placing  a  map 
symbol  on  top  of  or  near  them.  This  proved  especially  true  for 
linear  and  point  features  that  were  partially  occulted  by 
vegetation,  clouds,  or  other  spectral  influences.  Often,  just 
the  accurate  positioning  and  identification  of  certain  key  items 
allowed  the  eye  to  interpolate  the  location  and  nature  of  other 
nearby  items.  This  was  extremely  useful  for  control  point 
generation  in  areas  of  enigmatic  spectral  return.  AMS's 
mensuration  utilities  were  well  received  as  they  allowed  the 
analyst  to  measure  locations,  areas,  distances,  and  azimuths 
directly  off  the  image  display  screen. 

Often,  the  result  of  a  GIS/imagery  overlay  v;as  an  end  in 
itself.  The  pleasing  and  useful  combination  of  imagery  and  GIS 
information  with  its  associated  annotation  was  a  desirable 
product,.  Screen  capture  photographic  devices  should  be 
considered  when  designing  or  installing  GIS/imagery  overlay 
capabilities . 

CONCLUSION 
The  futures  of  image  processing  \>7orksta  tions  and  GIS 
workstations  will  become  increasingly  intertwined  as  the 
potential  for  extracting  complementary  data  from  each  is 
realized.  Many  GIS  products  hitting  the  market  today  are 
attempting  to  fuse  these  two  data  types  in  an  efficient  manner, 
but  as  with  many  new  products,  they  are  often  designed  for  a 
particular  suite  of  hardware  and  software,  lack  essential  GIS  or 
image  processing  components,  or  are  still  prohibitively 
expensive . 

I  hope  that  this  paper  has  shown  a  fairly  simple  technique 
that  will  allow  a  widely  available  GIS  software  package  to 
utilize  some  of  the  advantages  of  image  processing  technology 
without  much  additional  cost  or  serious  modifications  to  its 
software.  By  treating  an  image  processor  just  like  another 
digitizing  and  display  peripheral  with  a  slightly  more  elaborate 


driver,  many  of  the  best  benefits  of  merging  imagery  with  GIS 
data  are  effectively  realized  at  a  low  cost. 
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STATUS  OF  GIS  AT  BLM  OREGON 

The  Bureau  of  Land  hanagement  (BLM)  in  Oregon  has  been  using  Geographic 
Information  Systems  (GIS)  technology  based  on  the  Map  Overlay  and  Statistical 
System  (MOSS)  family  of  software  since  the  late  1970'5  on  a  series  of 
projects,  such  as  soil-vegetation  inventories.   BLM  Oregon  has  recently 
acquired  the  largest  single  Prime  9955-11  on  the  west  coast  dedicated  to  GIS 
processing,  with  6  gigabytes  of  disk  storage.   GIS  technology  will  be  the 
basis  for  the  upcoming  decadal  Resource  Management  Plans  (RMP)  for  five 
western  Oregon  BLM  districts  which  are  due  to  be  completed  in  1990. 
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0  begin  the  1990  RMP  effort,  it  was  necessary  to  develop  new, 

uniform  base  map  coverage  for  western  Oregon.   The  base  mapping 

to  the  Districts  consisted  of  a  conglomeration  of  maps  at  differing 

ntages,  quality  and  utility,  none  of  which  were  suitable  for  modern 

anageraent.   The  level  of  detail  needed  for  resource  management  in 

for  daily  use  is  at  a  scale  of  1:4,300  to  support  activities  such  as 

es,  road  benchmarking  and  landslide  studies.   This  data  is  then 

or  use  in  the  RMP  process  at  a  scale  of  1:12,000.   With  the 

t  of  microcomputer  applications  in  the  processing  of  the 

tted  data,  this  became  a  cost  effective  alternative  to  standard 

In  order  to  obtain  coverage  of  BLM's  2.4  million  acres  in  western 

otal  of  7.006  million  acres  are  being  mapped. 


The  delivery  of  a  stereo-plotted  digital  data  base  at  a  scale  of  1:4,800,  with 
>i,y,  and  z  coordinates  for  the  eventual  development  of  a  true  three 
dimensional  capability  is  a  major  breakthrough.   The  cost  of  the  delivered 
base  data  from  contractors  has  averaged  $0.31  per  acre  including  photography, 
control,  stereo-plotting,  and  compiling  into  a  GIS/MOSS  data  file. 

The  project  includes  a  Public  Land  Survey  System  grid  (PLSS)  created  utilizing 
Public  Land  Coordinate  Calculating  System  (PCCS)  software.   PCCS  provides  the 
link  from  the  ground  control  points  to  the  GIS  data  base  at  the  surveyors 
level  of  accuracy,  thus  creating  a  high  resolution  PLSS  grid  to  serve  as  a 
base  for  creation  of  land  status  and  Master  Title  Plats.   PCCS  is  verified 
manually  to  ground  panelled  control  points  and  compiled  into  an  MOSS  data 
file. 

The  base  thematic  data  being  captured  for  western  Oregon  includes  public  land 
survey  system,  transportation,  cultural  features,  hydrography,  gross 
vegetation  and  topography  at  20  foot  contour  intervals.   Approximately  20 
resource  themes  are  being  captured,  including  soils,  timber  production,  land 
status,  elk  distribution,  and  special  management  areas. 

Development  of  the  GIS  smart  terminal  by  BLM  Oregon  as  an  alternative  to 
expensive  high  resolution  dumb  color  terminals  has  led  to  substantial 
improvements  in  both  user  and  data  capture  processing  with  peripheral  GIS 
support.   The  GIS  smart  terminal  consists  of  an  AT  level  microcomputer  with  a 
GIS  module  including  a  high  resolution  19"  color  monitor,  Tektronix  emulator, 
AutoCAD  software  and  color  printer.   The  smart  terminal  serves  as  the  basic 
GIS/MOSS  digitizing  and  editing  terminal  workstation,  having  AutoCAD 
digitizing  capability  and  links  to  PC-based  data  base  management  software 
programs.   It  will  also  operate  the  new  MQSSlite  software  for  PC  GIS 
processing  (PC  version  of  MOSS  software). 


finother  development  is  the  Intelligent  Cursor  video  digitizing  module. 
MicroScience  Inc.  originally  developed  the  Intelligent  Cursor  as  a  medical 
microscanning  product.   This  $7,500  module  has  been  adapted  to  process  data 
into  AutoCAD  and  MOSS  files,  replacing  planned  procurement  of  a  $150,000  laser 
line  follower.   Use  of  the  Intelligent  Cursor  has  reduced  manual  digitising 
time  by  a  3:1  ratio.   Resource  data  already  mapped  on  aerial  photos  can  be 
captured  directly  which  will  further  increase  savings. 

6IS  processing  was  documented  to  establish  time  and  costs  to  project  the  level 
of  effort  needed  to  accomplish  the  project  within  RMP  timeframes.   Many 
resource  themes  which  were  digitized  manually  will  ultimately  be 
user-generated,  bypassing  manual  digitizing.   This  new  technology  using  a 
systems  integration  approach  to  capture  resource  themes  and  other  improvements 
will  reduce  substantially  the  costs  of  data  capture. 

The  value  of  gathering  this  digital  information  is  already  becoming  apparent. 
Resource  themes  have  been  digitized  showing  areas  to  be  cut  for  proposed 
timber  sales,  known  elk  habitats,  and  areas  targeted  as  potential  recreation 
sites.   When  these  themes  were  overlaid  with  new  updated  base  maps,  several 
potential  conflicts  were  noted.   Alternatives  can  now  be  developed  and 
analyzed  with  accurate  information  on  the  impacts  of  logging  (area/volumes) 
and  buffer  zones  established  to  protect  certain  areas.   By  enhancing  BLM's 
base  maps,  more  accurate  inventory  data  is  also  generated.   Accurate  data  is 
essential  for  effective  management  of  the  resources,  especially  with  the 
increased  emphasis  on  multiple  use  and  public  interest. 

For  further  information  on  GIS  activities  in  BLM  Oregon,  contact  Bob  Wright, 
GIS/Operations  Chief,  P.O.  Box  2965,  Portland,  Oregon  97208,  503-230-7535  (FTS 
429-7535).   For  information  on  the  western  Oregon  Resource  Management  Plans, 
contact  Phil  Hamilton,  Planning  Chief,  503-231-6256  (FTS  429-6256),  at  the 
same  address. 


THE  64,000  SQUARE  MILE  QUESTION: 
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US  Environmental  Protection  Agency,  Annapolis,  MD  21403 


Abstract 

EPA's  Chesapeake  Bay  Program  (CBP)  is  a  model  effort  in  estuarine 
management.  An  agreement  signed  in  1983  is  coordinating  the  minds  and 
money  of  both  federal  and  state  agencies  to  restore  and  protect  the 
once  most  productive  estuary  in  the  United  States.  The  committees  and 
task  forces  that  provide  scientific  support  to  the  Executive  Council  of 
federal  administrators  and  state  governors  are  using  a  gambit  of  tools 
to  do  their  work,  from  Secchi  disk  to  mathematical  models. 

The  unique  CBP  management  agreement  is  being  used  as  well  to  build  a 
GIS  data  base  for  the  64,000  square  mile  Chesapeake  Bay  watershed.  An 
attempt  is  being  made  to  identify  existing  digitized  data  bases  and 
establish  mechanisms  to  save  public  funds  increasingly  being  spent  on 
the  very  expensive  data  base  building  process.  This  paper  describes  the 
efforts  made  thus  far  and  planned  to  build  a  regional  Chesapeake  Bay  GIS 
data  base  at  the  CBP  Computer  Center  in  Annapolis,  MD.  Included  in  the 
paper  will  be  the  results  of  a  March  workshop  of  agencies  within  the  Bay 
watershed  working  on  data  base  development,  applications,  standards,  and 
documentation. 
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I.  THE  CHESAPEAKE  BAY  DRAINAGE  BASIN  covers  an  area  of  some  64,000 
square  miles.   It  encompasses  virtually  all  of  Maryland,  nearly 
half  of  Virginia  and  Pennsylvania,  and  portions  of  West  Virginia  and 
southern  New  York.  From  Landsat,  the  Bay  proper  seems  rather  small, 
about  10%  of  the  entire  drainage  basin.   It  does  however  have  far 
reaching  influence  on  millions  of  people  and  other  species  with  its 
arterial  network  of  over  150  rivers  and  streams  reaching  out  across 
the  land.  Its  resources  range  from  human  food  and  drinking  water,  to 
the  livelihood  of  a  billion  dollar  fisheries  industry. 

Of  the  eight  major  watersheds  in  the  Bay  basin,  approximately  60%  of 
the  freshwater  inflow  comes  from  the  originator  of  Chesapeake  Bay, 
the  Susquehanna  River.   About  a  million  years  ago,  the  Pleistocene 
glacial  melt  caused  the  Susquehanna  and  its  tributaries  to  overlow 
their  banks.  The  corresponding  rise  in  sea  level  submerged  the 
coastal  river  valley  to  form  the  Bay,  which  is  about  200  miles  long 
and  ranges  from  four  miles  wide  at  Annapolis,  MD  to  about  30  miles 
at  the  mouth  of  the  Potomac  River.  The  Bay  is  relatively  shallow, 
averaging  28  feet.  Portions  of  the  old  Susquehanna  river  bed  are 
over  150  feed  deep.  Fresh  water  inputs  from  the  tributaries  and 
the  influx  of  salt  water  from  the  Atlantic  Ocean  establish  the 
natural  fluctuating  limits  for  life  that  emerged  in  the  estuary. 

II.  BAY  USE  AND  ABUSE  is  often  hard  to  differentiate.  The  Bay  is  a 
complex,  diverse  ecosystem  that  reaches  farther  than  its  branches  of 
rivers  and  streams.  Water  that  originates  in  or  eventually  enters  the 
Chesapeake  is  pumped  inland,  away  from  its  source,  and  is  used  for 
ever thing  from  backyard  swimming  pools,  to  industrial  processing, 
agriculture,  and  drinking  water.  Sportfishing  and  recreational  boating 
are  favorite  individual  pastimes.   Commercial  uses  include  major 
harvesting  of  finfish  and  shellfish.  The  Bay  also  has  two  of  the 
largest  harbors  on  the  east  coast  at  Baltimore,  Md  and  Norfolk,  VA. 
These  inlets  are  havens  for  industry  and  transportation,  as  well  as 
military  bases  and  battle  fleets. 

These  and  many  more  human  uses  of  Chesapeake  Bay  are  taking  their  toll. 
Chesapeake  deserves  some  needed  R  &  R,  as  do  many  water  and  other  natural 
resources.  That  fine  line  between  use  and  abuse  is  even  more  difficult 
to  define  when  we  don't  even  understand  the  natural  variation  in  the 
Bay's  health,  let  alone  our  effects  on  it. 

Of  all  impacts  on  the  Bay,  human  population  growth  is  the  overriding 
factor.  Population  in  the  region  has  nearly  doubled  since  the  1950's. 
With  increases  in  humans  comes  increased  demand  on  water  use  and  its 
resources.  A  direct  result  of  increased  population  is  the  increase 
in  human  waste.   Sewage  treatment  plants  and  solid  waste  landfills  are 
being  taxed  to  the  limits  of  technology  and  becoming  obsolete  faster 
than  funds  can  be  directed  to  them.   Eighteen  billion  dollars  have 
been  identified  in  the  recently  enacted  Clean  Water  Act  for  sewage 
treatment  plant  construction  and  upgrading. 
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With  human  population  increase  comes  increases  in  development.  We 
continue  to  cover  more  land  with  concrete  roads,  offices  and  housing, 
which  replaces  natural  land  filtering  of  rainwater  with  storm  drain 
outfalls  that  empty  directly  into  our  streams  and  rivers.   Industrial 
growth  likewise  matches  population  increases.   Few  existing  sewage 
plants  are  geared  to  remove  the  toxic  chemicals  poured  down  the  drains 
of  manufacturing  and  processing  plants.  Worse  yet,  some  industrial 
wastes  that  contain  heavy  metals  or  other  toxic  substances  are  either 
being  poured  directly  into  the  water  or  stored  on  the  land  where  they 
eventually  leak  into  groundwater.   More  human  and  industrial  waste  is 
being  recycled,  but  not  fast  enough  to  continue  using  the  dilution 
solution  to  rationalize  the  effects  of  these  point  sources  of  pollution. 

Agriculture  runoff  is  proving  to  be  the  greatest  concern  for  the 
Bay's  health.  Mismanagement  of  farmland,  pasture,  and  feedlots 
has  caused  millions  of  tons  of  soil  and  animal  waste  to  be  washed 
into  the  streams,  and  delivered  to  the  Bay  each  year.   In  moving  water, 
these  nutrients  block  light  crucial  for  bottom  grasses  that  support 
a  wide  variety  of  species  that  are  critical  links  in  the  food 
chain.  Instead,  the  "fertile"  waters  cause  massive  algal  blooms 
that  die  off  and  consume  precious  oxygen  necessary  to  fish.  When 
the  nutrients  and  detritis  settle  out,  they  choke  off  bottom  dwelling 
organisms  as  well.  As  more  topsoil  washes  off  ag  land  and  pressure 
to  produce  increases,  chemical  additives  are  being  delivered  to  the 
Bay  with  the  soil.   Fertlizer,  pesticide,  and  herbicide  washoff  have 
increased  the  focus  on  this  non-point  source  of  Bay  pollution. 

III.  THE  CHESAPEAKE  BAY  PROGRAM  (CBP)  was  born  of  a  5-year  study 
commissioned  by  Congress  in  1975.  Numerous  studies  already  existed 
at  the  time  documenting  the  negative  effects  of  pollution  on  the  Bay, 
however  they  were  fragmented  and  did  not  address  some  serious  gaps  in 
our  scientific  knowledge  base.   In  1976,  the  Environmental  Protection 
Agency  (EPA),  in  cooperation  with  other  federal,  state  and  private 
institutions  began  a  concerted  effort  to  study  the  primary  sources  of 
Bay  pollution.  In  1981  the  research  phase  ended,  and  for  the  next  two 
years,  the  agencies  involved  analyzed  and  integrated  their  findings. 

Reports  from  this  scientific  research  phase  verified  what  alot  of 
people  already  knew,  but  more  importantly,  it  initiated  a  cooperative 
political  management  structure  to  address  the  problem.  In  September 
1983,  chief  executives  from  Maryland,  Pennsylvania,  Virginia, 
Washington  DC,  and  EPA  signed  the  Chesapeake  Bay  Agreement.  The 
parties  to  the  Agreement  called  for  preparation  and  implementation  of 
coordinated  plans  to  improve  and  protect  the  water  quality  and  living 
resources  in  the  Bay. 

IV.  CBP  MANAGEMENT  created  by  the  Bay  agreement  is  headed  by  an 
Executive  Council  comprised  of  the  agreement  signers.   The  Chair  of 
the  Executive  Council  rotates  between  EPA  and  each  of  the  agreement 
partners  each  year.  Their  first  order  of  business  was  to  develop  a 
committee  and  advisory  structure  that  reflected  the  number  of 
jurisdictions  involved  and  the  intricate  scientific  disciplines 
necessary  to  address  the  Bay's  problems. 


The  hierarchy  consists  of  three  committees,  the  Implementation, 
Scientific  and  Citizens  committes  that  advises  the  Executive  Council. 
The  Implementation  Committee  has  five  technical  subcommittees,  the 
Planning,  Modeling  and  Research,  Non-point  Source,  Monitoring,  and 
Data  Management,  to  advise  it.   Each  committee  and  subcommittee  have 
representatives  from  the  Bay  Agreement  organizations.   Chairship  of 
committees  and  subcommittes  is  spread  around  the  groups  involved. 

In  addition,  cooperative  agreements  have  been  signed  between  EPA  and 
other  federal  agencies  that  share  the  environmental  responsibility 
for  the  Bay.  These  agencies  include  the  National  Oceanic  and 
Atmospheric  Administration  (NOAA),  The  Army  Corps  of  Engineers  (COB), 
the  Fish  and  Wildlife  Service  (FWS),  the  Geological  Survey  (USGS),  and 
Soil  Conservation  Service  (SCS).  These  Memorandums  of  Understanding 
(MOU)s  were  intended  to  create  joint  ventures  of  scientists  and  managers 
to  make  more  efficient  use  of  public  funds  and  other  institutional 
resources  involving  Chesapeake  Bay. 

V.  THE  MANAGEMENT  GOAL  of  the  CBP  is  to  support  and  enhance  a 
cooperative  approach  at  all  levels  of  government.  As  part  of  each 
subcommittee's  charter,  this  goal  has  resulted  in  attempts  to  standardize 
programs  to  address  the  Bay's  three  priority  areas:   toxics,  nutrients, 
and  living  resources.  A  segmentation  scheme  representative  of 
circulation  and  salinity  patterns  divided  the  Bay  into  48  water  quality 
monitoring  stations  to  be  sampled  by  Maryland  and  Virginia.   Funds 
that  are  administered  by  EPA  have  been  used  for  a  wide  range  of  cost 
share  grants  for  water  quality  and  biological  monitoring.  Those 
monitoring  grants  have  resulted  in  3  years  of  data  that  can  be  analyzed 
across  state  lines. 

Implementation  grants  for  best  management  practices  (BMP)s  on  agcricultural 
land  to  keep  nutrients  and  toxics  out  of  the  water  have  been  coordinated 
throughout  the  region  as  well.  This  non-point  source  program  is  the 
largest  budgetary  item  for  CBP.  It  has  already  resulted  not  only  in 
saving  of  tons  of  pollutants  from  entering  the  Bay,  but  through  a 
broad  education  program,  is  proving  economical  to  farmers  as  well. 

Data  generated  from  the  above  two  programs  is  being  used  with 
historical  information  by  CBP  mathematical  modelers.  They  will  use 
the  data  to  validate  management  scenarios  that  test  various  baywide 
pollution  control  strategies. 

The  cooperative  mangement  goal  of  CBP  has  also  resulted  in  the  development 
other  common  management  tools,  including  monitoring  methods,  data 
standards  and  quality  objectives,  analytical  methods,  and  presentation 
techniques.   It  resulted  in  the  creation  of  the  CBP  Computer  Center,  which 
is  the  repository  of  Chesapeake  Bay  basin  data.  The  Data  Management 
Subcommittee  is  responsible  for  the  activities  of  the  CBP  Computer  Center 
and  the  development  of  all  data  related  policies.   It  is  here  that  GIS 
technology  surfaced  as  the  appropriate  data  management  tool  to  assist 
in  achieving  CBP  goals. 


VI.   THE  DATA  MANAGEMENT  SUBCOMMITTEE  AND  GIS  technology  had  a  shakey 
beginning  in  1984.  To  many  on  the  Subcommittee,  GIS  was  another  wishful 
solution  that  cost  alot  of  money  to  buy,  alot  of  time  to  support, 
and  alot  of  computer  resources.  They  were  skeptical  of  "trendy" 
technology,  learning  from  past  experiences  in  the  fast  growing  computer 
industry.  The  Subcommittee  is  also  trying  to  keep  demand  down  on  an 
already  overburdened  computer. 

Our  VAX  11/780,  purchased  in  1985,  supports  over  100  users,  up  to  24 
interactive  at  any  one  time.   Overnight  jobs  are  often  still  waiting 
to  be  executed  the  next  day.   Until  recently  most  Subcommittee  members 
agreed  that  the  existing  statistical  and  graphics  software  were  adequate 
to  support  the  Program's  mission. 

Arrival  of  GIS  on  the  CBP  scene  is  due  primarily  to  the  efforts  of 
US  Fish  and  Wildlife.   In  1985,  the  Subcommittee  sanctioned  a  pilot 
project  to  use  GIS  technology,  but  with  no  budget  or  equipment,  to 
target  non-point  source  areas  on  the  Choptank  River.  With  that  mandate, 
Jeff  Booth  and  Fred  Seavey  of  Fish  and  Wildlife  went  off  in  search 
of  the  only  public  domain  GIS  software  package,  one  developed  for 
NASA,  called  MOSS.   By  the  summer  of  1986,  it  was  apparent  that  MOSS 
could  not  do  the  job,  since  it  had  no  financial  support,  kind  of  like 
the  GIS  project  given  to  them. 

It  was  at  the  1986  Third  Annual  MOSS  Users  Conference  that  Jeff  Booth 
met  Cliff  Grieve,  president  of  Autometric,  Inc.  the  developer  of  MOSS, 
but  now  referred  to  as  AutoGIS.  Autometric  had  taken  the  most  recent 
version  of  the  MOSS  software  and  was  enhancing  it  on  a  contractual 
basis.   Jeff  convinced  Cliff  Grieve  that  using  the  CBP  as  a  beta 
site  for  his  VAX  version  of  AutoGIS  would  be  good  exposure.  By 
October,  not  only  did  CBP  have  AutoGIS  installed  on  the  computer, 
Jeff  convinced  Altek's  Don  Cameron  to  donate  a  digitizing  table  to 
the  cause.   In  the  meantime,  EPA  purchased  other  necessary  input 
and  output  devices. 

About  the  same  time,  CBPs  contractor,  Computer  Sciences  Corporation 
(CSC),  primarily  Lowell  Bahner  and  Lynda  Liptrap,  strong  proponents  of 
GIS,  performed  a  study  of  GIS  technology  and  its  appropriateness  to  the 
Program's  goals.   I  was  fresh  to  the  Program  and  the  Subcommittee,  as 
well  as  to  GIS.  After  hands-on  training  with  MOSS  at  the  University  of 
Missouri,  and  reviewing  the  draft  CBP  GIS  Report  by  CSC,  I  was  a  firm 
believer.  Upon  editing  the  CSC  report,  I  took  it  to  the  Subcommittee 
with  recommendations  to  implement  a  GIS  program  that  included  building 
a  digitized  data  base  for  the  applications  already  identified,  purchasing 
additional  software  and  hardware,  and  establishing  a  regional  workgroup 
to  address  the  obvious  and  hidden  issues  inherent  in  the  technology. 
The  Subcommittee  approved. 


VII,  WHY  GIS  FOR  CBP?  The  primary  justification  for  GIS  Technology 
is  that  CBP's  other  mapping  (MAPIT)  and  graphics  (SAS,  Surface  II) 
software  are  inadequate  for  the  current  program  applications. 

CBP  is  in  a  developmental  stage  called  Implementation  Phase  II.  This 
stage  requires  the  collection  and  storage  of  more  spatial  data  as 
opposed  to  point,  or  parameters  that  contain  multiple,  connected 
points  represented  by  geographic  coordinates.   For  example,  defining 
distribution  of  a  particular  species  of  vegetation  or  location  of  the 
spawning  area  of  a  certain  finfish  in  the  Bay  requires  a  unique  data 
management  tool.  A  GIS  is  the  appropriate  software  tool  to  collect  and 
store  this  type  of  data. 

The  spatial  data  being  collected  during  Phase  II  Implementation  are 
required  for  very  specific  types  of  analysis.  CBP  managers  are  asking 
questions  that  require  comparing  various  types  of  geographically 
dependent  data.  This  means  being  able  to  search  a  data  base  for  striped 
bass  spawning  areas  that  are  in  waters  within  a  range  of  dissolved  oxygen 
or  other  survival  dependent  habitat  parameters.   A  GIS  is  the  software 
tool  to  provide  this  type  of  analysis  of  different  types  of  data  from 
various  sources,  at  different  scales.   Other,  more  common  analytical 
packages  cannot  provide  this  type  of  geographic  based  comparison. 

CBP  Implementation  Phase  II  also  requires  the  ability  to  display  and 
present  the  spatial  data  analysis  results  in  a  meaningful,  consistent 
manner  to  management.  Congress,  and  the  public.  Graphic  representation 
using  multi-color,  shaded  maps  is  far  more  attractive  and  informative  to 
a  non-technical  audience  than  tabular  or  x,y  cordinate  line  graphs.  A 
GIS  is  again  the  software  that  allows  multiple  types  of  data  to  be 
displayed  on  easily  recognized  base  maps. 

CBP  is  a  joint  effort  of  federal  and  state  agencies.  EPA  is  behind  other 
agencies  with  environmental/geographic  regulatory  missions  when  it  comes 
to  using  the  appropriate  technology.  The  US  Fish  and  Wildlife  Service, 
US  Geological  Survey,  the  Soil  Conservation  Service,  the  State  of 
Maryland,  and  Commonwealth  of  Virginia  are  all  using  GIS  technology. 
Since  EPA  serves  as  the  lead  federal  agency  of  CBP  and  in  environmental 
protection,  we  should  at  least  have  the  tools  to  communicate  with  our 
Program  partners,  and  more  often  be  a  leader  in  state-of-the-art 
technology.  GIS  technology  that  is  implemented  at  the  Bay  Program  can 
be  shared  with  other  EPA  programs  so  that  start-up  time  for  future 
projects  can  be  reduced  and  lessons  learned  can  be  passed  on. 

VIII.  CBP  GIS  IMPLEMENTATION  has  mushroomed  compared  with  the  time 
it  took  to  get  over  the  kinetic  threshold  of  resistance.   EPA  has  a 
full-time  staff  person  for  GIS,  who  is  managing  a  nationwide  GIS  needs 
study  for  the  agency.  CBP  is fa\nowj pilot  GIS  project  site  that  EPA 
will  use  to  develop  agencywide  standards  for  procurement  and  other 
policies.   In  March,  CBP  held  a  Chesapeake  Bay  GIS  Conference  that 
attracted  nearly  100  representatives  from  around  the  region  who 
either  already  had  GIS  projects  in  place  or  was  investigating  the 
feasibility  of  the  technology.   Out  of  that  conference,  a  workgroup 
was  formed  of  the  various  federal,  state,  and  local  agencies  within 
the  basin. 


IX.   GIS  PROJECTS  IN  THE  CHESAPEAKE  BAY  BASIN 
PROJECT  NAME:   Patuxent  Watershed  Model 


DESCRIPTION: 


AGENCY  NAME: 


Development  of  a  multi-level  (layer)  data  base  for  the 
Patuxent  River  watershed.   Data  layers  to  be  included  are 
soils,  land  use,  transportation,  hydrologic  boundaries, 
political  boundaries,  wetlands,  public  lands,  and  living 
resources. 

MD  Department  of  Natural  Resources 
Program  Open  Space 
2012  Industrial  Drive 
Annapolis,  MD  21401 


PROJECT  NAME: 
DESCRIPTION: 


Maryland  Automated  Geographic  Information  System  (MAGI) 

The  MAGI  system  is  a  comprehensive  grid  cell  based  GIS 
of  natural  resources  data  for  Maryland.   The  system 
provides  the  capability  to  retrieve  and  manipulate 
various  forms  of  geographic  data  (i.e.  soils,  land 
use,  county  comprehensive  plans,  etc.)  and  display  the 
results  as  tabular  reports  and  maps.   Since  its  origin 
in  1974,  MAGI  has  been  used  extensively  by  state, 
federal,  and  local  government  agencies,  as  well  as 
colleges,  universities,  and  private  industry  to  analyze 
land  and  water  resource  data. 


AGENCY  NAME: 


Maryland  Department  of  State  Planning 
Office  of  Planning  Data 
301  West  Preston  Street 
Baltimore,  MD  21201 


PROJECT  NAME:   STATSGO  Pilot  Project 


DESCRIPTION: 


AGENCY  NAME: 


A  cooperative  project  to  do  a  pilot  test  of  the  State 
General  Soil  Geographic  (STATSGO)  data  base.   The  Soil 
Conservation  Service  (SCS)  is  providing  digital  line 
data  and  soil  attributes  for  soil  associations.  The 
US  Geological  Survey  (USGS)  is  processing  the  data  to 
make  interpretive  maps  and  to  test  the  data  with  other 
data  layers  from  their  National  Digital  Cartographic 
Information  Center  (NCIC)  data  base. 

Soil  Conservation  Service 
Cartographic  and  GIS  Division 
US  Department  of  Agriculture 
P.O.  Box  2890,  Rm  6245-S 
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PROJECT  NAME: 
DESCRIPTION! 


AGENCY  NAME: 


Virginia  Geographic  Information  System  (VirGIS) 

Developed  by  the  Agricultural  Engineering  Department, 
Virginia  Tech,  to  assist  in  targeting  Virginia's 
agricultural  land  with  the  greatest  potential  for 
delivering  sediment  to  the  nearest  stream.   The  data 
base  consists  of  grid  cells  referenced  to  the  UTM 
coordinate  system,  and  averaged  over  one  hectare 
cells.  Elevation  is  averaged  over  4  hectare  cells. 

Virginia  Division  of  Soil  and  Water  Conservation 
203  Governor  Street 
Suite  206 
Richmond,  VA  23227 


PROJECT  NAME: 
DESCRIPTION: 

AGENCY  NAME: 


Choptank  River  Pilot  GIS 

A  regressions  model  using  GIS  technology  to  relate 
land  use  changes  with  nutrient  loadings  and  identify 
high  priority  non-point  source  pollution  areas. 

US  Fish  and  Wildlife  Service 
Annapolis  Field  Office 
1825  Virginia  Street 
Annapolis,  MD  21401 


PROJECT  NAME: 
DESCRIPTION: 


AGENCY  NAME: 


Elizabeth  River  Pilot  Project 

A  cooperative  project  between  the  US  Environmental 
Protection  Agency  and  the  US  Geological  Survey  to 
demonstrate  GIS  technology  to  identify  and  assess 
toxic  sources  of  pollution  in  the  Elizabeth  River  at 
Norfolk  Harbor.  USGS  transportation  and  hydrology 
data  were  digitized  from  EPA's  Environmental  Photo 
Interpretation  Center  aerial  photography.   For  the 
first  time,  historic  land  use  data  is  being  used 
on  a  GIS  to  identify  potential  hazardous  waste  sites. 

US  Geological  Survey 
Water  Resources  Division 
3600  West  Broad  Street,  Rm  606 
Richmond,  VA  23230 
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X.  THE  CHESAPEAKE  BAY  GIS  WORKGROUP  met  for  the  first  time  on  May  15. 
Our  first  order  of  business  was  to  refine  the  information  that  will 

be  published  as  the  Chesapeake  Bay  GIS  Atlas  and  kept  updated  on  the 
CBP  computer  information  network.   The  workshop  defined  the  scope  and 
format  of  the  Atlas,  starting  from  an  initial  project  listing  and 
eventually  becoming  a  sort  of  GIS  yellow  pages.   The  ultimate  product 
would  provide  a  user  interested  in  GIS  data,  with  sources  and  caveats 
as  to  data  quality  and  uses. 

We  also  further  outlined  data  needs  for  existing  and  anticipated  GIS 
applications.  Many  of  the  groups  involved  have  similar  data  needs. 
As  these  data  sources  are  identified,  we  are  finding  additional 
participants  for  our  workgroup. 

Most  important,  the  workshop  participants  began  to  discuss  mechanisms 
to  share  existing  GIS  data  and  how  to  generate  data  in  other  formats. 
Our  goal  is  to  provide  the  technology  and  data'^'those  in  the  basin  that 
need  it,  and  to  do  so  for  the  least  expenditure  of  time  and  money. 

XI.  THE  FUTURE  OF  GIS  TO  CBP  is  lit  with  excitement  by  all  involved. 
We  feel  that  upper  management  is  aware  of  GIS  technology  and  its 
potential  benefit  to  the  Program  through  small,  low-budget  examples, 
and  the  mechanisms  in  place  to  make  the  most  of  any  investment.  We 
are  confident  that  GIS  will  be  an  asset  to  the  many  other  tools  used 
to  make  science  more  of  a  part  in  the  political  decision-making 
process  to  protect  Chesapeake  Bay. 
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EVALUATION  OF  THE  REDLINE  STAGE 


FARMINGTON  DEMONSTRATION  PROJECT 


by 


Ader,  Robert,  Service  Center 
Balkus,  Carol,  Farmington  Resource  Area 
Bright,  Judith,  Service  Center 
Candelaria,  Mike,  Farmington  Resource  Area 
Collins,  Dana,  Infotec  Data  Products 
Culley,  David,  TGS  Technology,  Inc., 
Cummins,  Dale,  Colorado  State  Office 
Edge,  David,  Alaska  State  Office 


Foster,  Jon,  California  State  Office 
Graff,  Greg,  Service  Center 
Keating,  Bruce,  Wyoming  State  Office 
Lovato,  Jim,  Farmington  Resource  Area 
Montgomery,  Sam,  Farmington  Resource  Area 
Nighbert,  Jeff,  New  Mexico  State  Office 
Precosky,  Louise,  New  Mexico  State  Office 
Speight,  Gary,  New  Mexico  State  Office 


DESCRIPTION 


A.   PURPOSE 

The  purpose  of  the  Redline  Phase  of  the  Farmington  Demonstration  Project 
was  to  demonstrate  in  a  field  office  environment  the  linkage  of  records, 
resources,  and  coordinates  to  improve  land  based  decision  making.   The  project 
assisted  the  Bureau  in  defining  functional  and  system  requirements  for  an 
interim  Land  Information  System  (LIS)  and  helped  clarify  functional  and  system 
requirements  for  a  future  US. 

The  Farmington  Resource  Area  was  chosen  for  the  demonstration  because  of 
its  large  and  diverse  workload.   The  Bureau  also  believed  Farmington  would 
provide  a  field  environment  where  more  comprehensive  potential  Bureauwide 
applications  could  evolve.   (Figure  1  shows  the  location  and  coverage  of  the 
Study  Area. ) 


The  Application  for  Permit  to  Drill  (APD)  was  selected  as  the  vehicle  for 
the  test  because  its  requirements  for  processing  data  are  similar  to  a  number 
of  other  case  processing  functions  in  the  Bureau. 


FIgur*     1        Location    of    tho     F a r m i n 9 t o n     Project     Araa 
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B.   SCOPE  OF  THE  REDLINE 

The  Redline  was  conducted  primarily  by  the  New  Mexico  State  Office  (NMSO), 
Division  of  Operations,  with  assistance  from  the  following: 

o  Albuquerque  District  Office 

o  Farmington  Resource  Area 

o  Service  Center  (SC) 

o  U.S.  Department  of  the  Interior,  Geological  Survey  (USGS) 

The  NMSO  utilized  a  limited  number  of  highly  skilled  personnel  for  the 
demonstration  project.  Many  offices  in  the  Bureau,  however,  do  not  have 
personnel  with  the  skills  exhibited  by  the  Division  of  Operations  Staff  for 
constructing  CIS  data  bases.   A  thorough  knowledge  of  the  Automated  Digitizing 
System  and  Map  Overlay  and  Statistical  System  (ADS/MOSS)  and  Data  General's 
(DG's)  operating  system  and  utilities,  along  with  computer  systems  support 
staff,  were  required.   Although  preliminary  efforts  were  made  to  prepare  data 
and  selected  programs,  most  of  the  accomplishments  were  conducted  over  an 
8-week  period,  from  December  1986  through  January  1987. 

The  Project  primarily  used  existing  NMSO  hardware  and  software 
capabilities.   An  additional  program  was  written  to  generate  geographic 
coordinates  for  oil  and  gas  wells  from  footage  calls.   Macros  were  also 
developed  by  using  DG's  Advanced  Operating  System  (AOS),  REV  7.2,  to  assist 
with  data  reformatting  and  to  improve  and  simplify  data 
processing. 

The  Redline  effort  followed  three  major  steps: 

o   Acquisition  of  Data:   Data  requirements  were  identified  and  requests 
were  made  to  obtain  information  appropriate  for  the  data  base. 

o   Data  Base  Construction:   Data  were  reformatted  and  loaded  onto  the  DG; 
the  data  base  was  constructed  for  a  nine-township  area. 

o   Use  of  the  System:   Macros  were  developed  and  used  to  demonstrate 

tools  available  for  processing  an  APD  and  for  generating  Master  Title 
Plats  (MTPs). 

C.   HARDWARE  CONFIGURATION 

Most  of  the  work  was  done  on  the  DG  Model  M600  computer  at  the  NMSO.   This 
system  was  used  for  constructing  the  data  base  and  for  processing  all  land 
information.   Additional  tasks,  such  as  initial  retrieval  of  Case  Recordation 
and  Status  data,  were  performed  on  the  Honeywell  DPS8  at  the  SC. 


D.   SOFTWARE  CONFIGURATION 

Software  consisted  primarily  of  the  following  existing  Geographic 

Information  System  (GIS)  software  packages  and  specialized  macros  written  with 
the  AOS: 

o   Automated  Digitizing  System  (ADS) — Captures,  displays,  and  edits 
mapped  information  in  a  vector/coordinate  format. 

o   Map  Overlay  and  Statistical  System  (MOSS) — Processes  and  displays 
mapped  information  in  vector  or  raster  formats. 

o   Map  Analysis  Package  (MAP) — Processes  and  displays  mapped  information 
in  a  raster  format. 

o   Public  (land  survey)  Coordinate  Computation  System  (PCCS) —  Computes 
geographic  coordinates  based  on  surveyed  bearings  and  distances. 

The  following  programs  are  conceptually  part  of  the  GIS  packages  but  were 
written  separately  in  FORTRAN  77  to  expedite  the  transfer  of  software  to  Prime 
computers. 

o   Generate  Geographic  Well  Location  (GGWL) — Generates  geographic 
coordinates  for  wells,  based  on  legal  descriptions  (meridian, 
township,  range,  section  plus  footages). 

o   Interactive  Generation  of  Geographic  Well  Location  (INTGGWL) — 

Provides  a  user  interface  to  capture  legal  descriptions  of  well 
locations. 

o   PCCS2ADS — Converts  PCCS  data  to  ADS  and  generates  section  lines  for  a 
township. 

o   Parcel  Generator — Generates  land  parcels  based  on  legal  land 
descriptions  and  land  net  coordinates. 

o   PGFORMAT — -Provides  a  capability  to  interactively  create  a  file  of 
legal  land  descriptions  for  Parcel  Generator. 

Systems  operations  and  macro  development  were  performed  with  DG's  Command 
Line  Interpreter  (CLI)  of  AOS,  Revision  7.2;  Screen  Editor  (SED);  SORT/MERGE; 
and  Report  Writer.   Several  macros  were  developed  to  set  graphics  terminal 
characteristics  and  to  provide  a  simplified  user  interface;  however,  the 
macros  were  primarily  used  to  assist  in  reformatting  data. 
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ACQUISITION  OF  DATA 


A.   ACQUISITION  PROCEDURES 

1.  Coordinate  Data. 

Coordinate  data  were  available  from  three  sources.   Digitized  and 
generated  coordinates  were  collected  at  the  NMSO,  while  computed  coordinates 
from  surveys  were  provided  through  the  cooperative  efforts  of  the  New  Mexico, 
Colorado,  and  Oregon  State  Office  Cadastral  Survey  staffs.   Coordinate  data 
were .... 

o   Generated  to  produce  generic  rectangular  coordinates  (based  on  a 
standard  township). 

o   Digitized  from  USGS  7  l/2-minute  quadrangles. 

o   Computed  based  on  satellite  positioning  and  conventional  survey 
methods. 

2.  Records  Information. 

o  Status  data  were  requested  from  the  Automated  Land  and  Mineral 
Record  System  (ALMRS)  Coordinator  in  the  NMSO.   Status  was 
downloaded  from  the  New  Mexico  ALMRS  data  base,  reformatted  at  the 
SC,  and  delivered  on  tape. 

o  Case  Recordation  data  were  requested  of  the  ALMRS  Project  Office  at 
the  SC  and  delivered  to  the  New  Mexico  State  Office.   Oil  and  gas 
leases  were  contracted  from  this  data  set. 

o  Panel  maps  were  requested  in  hardcopy  (nondigital)  format  from  the 
Albuquerque  District  Office.   These  maps  portrayed  the  boundaries 
of  Communitization  Agreements  (CAs),  Unitized  Agreements  (UAs)  with 
participating  areas,  and  Known  Geologic  Structures  (KGSs). 

3.  Resource  Information. 

o  A  number  of  resource  data  themes  were  already  available  in  digital 
format  at  the  NMSO  from  Farmington's  Resource  Management  Plan. 
Available  themes  included  cultural  sites,  paleontology,  mineral 
ownership,  and  wildlife  habitats. 


o  Resource  maps  were  obtained  from  the  Farmington  Resource  Area  for 
digitizing.   Since  the  original  maps  could  not  be  released,  the 
data  were  transcribed  onto  USGS  7  1/2-minute  topographic  maps  for 
shipment.   Map  themes  included  roads,  allotment  boundaries,  and 
range  improvements . 

o   The  request  for  Petroleum  Information,  Inc.  (Pl)  data  was  made  to 
USGS,  Division  of  Water  Resources  by  the  District  Office,  while 
acquisition  of  other  themes  through  USGS  was  coordinated  through 
the  ALMRS  Project  Office.   PI  data  were  delivered  to  the  NMSO  and 
Digital  Elevation  Models  (OEMs)  were  delivered  to  the  SC  for 
preprocessing  but  data  were  not  used  because  of  delivery  schedules 
and  time  constraints.   Transportation  and  hydrography  data  were  not 
delivered.   (Roads  were  digitized  after  nondelivery  became 
evident. ) 

B.  ISSUES,  PROBLEMS,  AND  SOLUTIONS 

The  Redline  experience  showed  that  data  acquisition  deserves  considerable 
attention  in  future  projects.   The  delays,  resulting  from  late  delivery  or 
nondelivery  of  data,  placed  serious  time  constraints  on  the  project.   In  these 
cases,  a  third  party  was  usually  involved.   While  this  may  not  have  been  the 
only  reason  for  inadequate  response,  it  almost  certainly  complicated 
communications. 

C.  RECOMMENDATIONS 

Third-party  arrangements  for  acquiring  data  should  be  avoided.   Requests 
should  be  made  in  writing  and  contingency  plans  should  be  made  to  accommodate  ' 
potential  problems.   Knowing  early  in  the  process  that  data  will  be  late  or 
unavailable  can  allow  adequate  time  for  rescheduling  or  making  other 
arrangements  to  acquire  the  data.   Every  attempt  should  be  made  to  establish 
and  maintain  direct  communications  with  data  sources  and  to  work  on  potential 
problems  early  in  the  process.   Thus,  adequate  time  must  be  allowed  to  acquire 
data,  especially  if  data  must  be  obtained  from  other  sources. 


DATA  BASE  CONSTRUCTION 


A.   COORDINATE  DATA 

1.   Description  of  Procedures. 

Bearings  and  distances  obtained  from  the  resurvey  field  notes  were 
entered  into  the  PCCS  program  to  produce  a  digital  file  of  adjusted  Universal 
Transverse  Mercator  (UTM)  geographic  coordinates  for  each  township.   This 
file,  produced  on  the  SC  Honeywell  DPS  8,  was  reformatted  and  transferred  to 
the  MOSS  software  on  the  DG  M600.   Several  SORT/MERGE  macros  were  written  to 
correct  record  length  and  record  delimiters  as  well  as  to  make  changes  to 
octal  format.     (Figure  2  shows  a  sample  file  created  with  PCCS.) 
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Flgur*     2        SampI*     Flla     Created     with     th«     PCCS     Program 
(UTM*     appaar     in     far     right     flalds.) 


The  PCCS2ADS  program  was  used  to  convert  geographic  coordinates  to 
section  boundaries  into  ADS  line  maps  from  which  a  township  map  of  the  Public 
Land  Survey  System  (PLSS)  was  produced.   Figure  3  shows  a  sample  township 
output  product.   Coordinates  not  on  a  section  boundary  were  converted  to  ADS 
as  a  symbol  file.   The  ADS  maps  were  then  transferred  by  MOSS  so  they  could  be 
used  as  base  maps  for  resource  analysis.   Figure  4  shows  the  flow  of  the  data 
base  construction  process  used  in  the  project. 

2.   Problems,  Issues,  and  Solutions. 

The  main  problem  was  nonstandard  data  exchange  formats.   The  PCCS 
file,  transferred  to  the  DG,  was  visually  reviewed  before  PCCS2ADS  was 
executed  and  some  incompatibilities  were  corrected  using  SED.   Specifically, 
record  length  was  changed  and  carriage  returns  were  added.   When  the  file 
seemed  correct  to  PCCS2ADS  import  specifications,  the  program  was  executed. 
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Flgur*     4        Coordlnat*     Data     Flow     Diagram 


NMSO  had  to  write  a  macro  to  convert  Honeywell  ASCII  to  standard  ASCII  format 
before  PCCS2ADS  could  be  successfully  executed. 

The  PCCS2ADS  handles  only  standard  townships  in  UTM  coordinates  and 
generates  section  lines  based  on  the  coordinate  coding  method  in  PCCS.   Thus, 
some  section  boundaries  may  have  to  be  edited  in  ADS.    Since  PCC2ADS  cannot 
process  townships  containing  meander  lines  or  metes  and  bounds,  this 
information  must  be  digitized. 

For  those  coordinates  used  to  generate  the  graphic  in  Figure  3,  the 
associated  reliability  factors  resulting  from  the  transfer  are  from  10  to  30 
feet.   This  means  that  coordinate  or  map  point  represents  an  on-the-ground 
accuracy  of  from  10  to  30  feet  of  its  actual  location.   PCCS2ADS  maintains  the 
accuracy  of  the  coordinates  generated  with  PCCS. 

3.   Recommendations . 

a.  To  avoid  miscommunication  of  tape  specifications  including  record 
length  and  carriage  returns,  written  statements  with  proper  tape 
specifications  are  recommended. 

b.  Writing  macros  to  accommodate  nonstandard  ASCII  format  is 
time-consuming  and  difficult  for  the  average  user.   These  kinds  of  macros  or 
similar  programs  should  be  automatically  executed  during  data  conversion  and 
remain  invisible  to  the  user. 

c.  PCCS2ADS  should  be  modified  to  accommodate  townships  containing 
meanders  and  metes  and  bounds  to  increase  its  potential  for  other  applications. 

d.  Information  contained  in  the  geographic  coordinate  data  base 
should  meet  most  of  the  needs  of  private  and  public  users.   In  addition,  the 
user  interface  and  indexing  system  (i.e.,  the  ability  to  select  information  by 
township,  range,  section,  county,  and  state)  should  be  compatible  with 
commonly  used  conventions  and  data  formats.   Thus,  file  formats  and 
processing  procedures  should  be  standardized  and  documented. 

B.   RECORDS  DATA 

1.   Description  of  Procedures. 

Parcel  Generator  was  used  to  generate  digital  maps  from  alphanumeric 
legal  descriptions  and  land  net  coordinates.   The  record  input  data  format 
required  for  Parcel  Generator  was  modeled  after  Legal  Land  Description  (LLD) 
Status  collection  standards.   These  formats  include  status  types  L,  9,  A, 
and  3.   Other  LLD/Status  data  formats  are  flagged  as  errors  by  the  program. 

This  Parcel  Generator  allowed  records   to  be  processed  with  the  township  grid 
data  in  ADS  to  generate  geographically  referenced  maps.   These  maps  showed 
land  ownership,  oil  and  gas  leases,  KGS  areas,  UAs,  CAs ,  and  well  locations 
through  various  line  types,  color,  and  shading.   The  Parcel  Generator  program 
was  used  to  subdivide  sections,  using  only  coordinates  falling  on  section 
boundaries.   Although  interior  section  coordinates  were  transferred  to  ADS  as 
a  symbol  file,  they  could  not  be  used.   The  maps  can  be  stored,  accessed,  and 
plotted  by  Public  Land  Record  users  with  very  little  computer  experience. 


The  format  for  collecting  status  is  defined  in  the  Status  Coding  Handbook, 
using  Application  2002  of  the  Data  Element  Dictionary.   Figure  5  shows  an 
example  of  one  status  data  format.   Oil  and  gas  lease  information  from  Case 
Recordation  was  provided  as  "raw"  data,  which  required  macro  programs  to  sort 
and  reformat.   Figure  6  shows  an  example  of  reformatted  Case  Recordation 
data.   The  KGS,  CA,  and  UA  legal  descriptions  were  interpreted  from  the 
hardcopy  panel  maps,  coded  and  entered  in  a  status  format.   PG  Format  was  used 
to  enter  the  data.   All  records  data  were  processed  with  Parcel  Generator  to 
produce  graphics  of  surface  ownership,  oil  and  gas  leases,  KGS,  CAs,  and  UAs. 
Figures  7  and  8  show  patented  lands  and  oil  and  gas  lease  boundaries, 
respectively,  which  were  computed  with  Parcel  Generator.   Figure  9  displays 
the  data  flow  for  records  information. 

2.   Problems,  Issues,  and  Solutions. 

a.  Standardization 

A  major  problem  encountered  with  records  data  was  the  lack  of 
standards  for  collecting  and  coding.   Surface  ownership  and  oil  and  gas  lease 
information  had  been  collected  in  various  formats,  independent  of  the 
project.   Additionally,  the  size  of  fields  varied  for  oil  and  gas  lease 
information,  requiring  it  to  be  sorted  and  reformatted. 

b.  Time 

Oil  and  gas  lease  information  was  received  8  weeks  after  requested, 
partially  because  programs  had  to  be  developed  to  retrieve  only  oil  and  gas 
data  from  the  more  extensive  Case  Recordation  files  at  the  SC.   The 
development  of  programs  for  sorting  and  retrieving  data,  and  the  subsequent 
processing  of  the  data  at  the  NMSO  to  standardize  exchange  formats,  required  a 
considerable  amount  of  time.   Many  of  the  sorting  and  retrieval  requirements 
could  have  been  handled  more  effectively  with  an  Relational  Data  Base 
Management  System  (RDBMS). 

c.  Parcel  Generator  Limitations 

The  Parcel  Generator  software  could  not  interpret  oil  and  gas  lease 
data  described  in  normal  legal  conventions  for  distance  and  bearings,  offset 
measurements,  or  descriptive  free  formats.   While  free-format  descriptions 
will  require  entering  data  manually,  distance  and  bearings  and  offset 
measurement  capabilities  could  realistically  be  developed  for  the  software. 

The  existing  Parcel  Generator  software  also  has  difficulties 
dissolving  duplicate  lines  where  legal  descriptions  for  the  same  lands  are 
given  more  than  once,  resulting  in  additional  editing  through  ADS.  If  not 
edited,  overlapped  areas  become  separate  polygons  in  ADS.   Additionally,  the 
program  does  not  use  coordinates  interior  to  the  section  boundaries. 

The  Parcel  Generator  cannot  produce  maps  from  record  data  unless 
coordinate  locations  fall  on  a  section  boundary.   Coordinates  interior  to  the 
section  are  computed  based  on  standard  rules  for  subdividing  by  aliquot  part 
and  regular  lots. 
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Figure   9     Data  Flow  for  Records   Information 


Parcel  Generator  can  best  be  used  with  entire  townships;  but  the 
user  may  specify  individual  sections.   If  an  entire  township  is  not  included 
on  a  USGS  quad,  data  in  the  sections  that  fall  on  quadrangle  boundaries  must 
be  captured  by  digitizing  in  ADS.  However,  a  program  called  EXTRACT  has  been 
developed  that  retrieves  the  appropriate  portions  of  a  township  from  multiple 
quads  and  merges  them  into  a  single  map.   The  resulting  township  can  be 
effectivel}/'  used  by  the  Parcel  Generator. 

d.   Updating 

An  operational  concern  is  keeping  Case  Recordation  data  current. 
Once  the  case  records  were  processed  to  produce  graphics,  using  data  from  the 
Honeywell  DPS  8,  the  dynamics  of  the  case  records  were  lost.   The  ability  to 
update  alphanumeric  case  records  and  graphics  must  be  recognized  as  a  vital 
link  in  the  system.   Case  records  must  be  continually  updated  to  reflect 
actions  occurring  on  the  leases  via  State  adjudication  decisions  because  these 
actions  affect  BLM  field  decisions  on  post-lease  activity. 

3.   Recommendations . 

The  conversion  of  land  record  information,  such  as  oil  and  gas  lease 
boundaries,  from  legal  descriptions  in  the  case  recordation  files  to 
geographic  locations,  was  a  significant  component  of  the  Redline.   This 
conversion  effort  utilized  existing  oil  and  gas  lease  information  from  Case 
Recordation  along  with  the  Parcel  Generator  software,  reducing  the  need  for 
digitizing  and  demonstrating  the  capability  to  merge  records  data  with 
resource  data. 

The  Parcel  Generator  software  is  based  on  standard  aliquot  part 
surveying  conventions  and  will  probably  be  effective  in  80  percent  of  the 
applications  where  legal  descriptions  and  land  net  follow  these  conventions. 
The  remaining  20  percent,  representing  nonstandard  surveying  situations,  will 
require  editing  or  digitizing.   Parcel  Generator  should  be  used  with  the  most 
accurate  land  net  data  available  and  should  be  enhanced  to  use  coordinates 
interior  to  section  boundaries  to  make  full  use  of  survey  information  in 
generating  township  grid. 

With  the  capability  to  convert  legal  descriptions  to  geographic 
locations,  the  Parcel  Generator  can  potentially  be  used  in  other  applications, 
such  as  providing  check  plots  to  assure  the  accuracy  of  legal  land  records, 
automating  MTPs,  and  improving  graphic  accuracy  by  incorporating  current 
survey  information  from  PCCS. 

Because  data  were  collected  in  a  nonstandard  format,  sorting  and 
reformatting  were  major  problems.   The  data  provided  from  Case  Recordation 
should  be  standardized  by  developing  a  sort/reformat  program  to  improve 
consistency  and  increase  immediate  utility.   This  requires  establishment  and 
adherence  to  Bureauwide  data  standards.   The  availability  could  also  be 
significantly  improved  by  allowing  the  State  Offices  with  current  GIS 
configuration  to  access  and  copy  files,  rather  than  only  obtain  reports. 


I 
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Data  management  and  manipulation  capabilities  could  be  improved  by 
adopting  an  RDBMS  that  allows  the  user  to  select  and  use  combinations  of  data 
from  a  single  file.   This  capability  could  also  be  used  to  maintain  and  update 
case  recordation  files,  keeping  data  current  and  valid. 

C.    RESOURCE  DATA 

1.  Description  of  Procedures. 

The  APD  checklist  provided  guidance  for  entering  resource  themes 
into  the  data  base.   Resource  themes  included  threatened  and  endangered 
species,  allotment  boundaries,  hydrography,  roads,  paleontological  sites, 
wildlife  habitats,  and  range  improvements.   Some  of  these  data  themes  were 
drafted  on  maps  in  the  Farmington  Resource  Area  Office;  however,  some 
inventories,  such  as  range  improvements  and  cultural  surveys  remained 
incomplete.   These  maps  were  duplicated  and  copies  were  sent  to  the  State 
Office  for  digitizing. 

The  PI  well  data,  were  furnished  on  magnetic  tape  in  a  flat-file 
text  format.   The  file  was  loaded  and  the  DG  SORT/MERGE  utility  was  used  to 
search  for  and  identify  missing  records.   The  locations  of  wells  in  the  file 
were  referenced  by  footage  calls  from  section  lines  as  well  as  by  actual 
geographic  coordinates. 

A  program  called  GGWL  computed  additional  geographic  coordinates  for 
wells  by  referring  to  the  ADS  map  of  the  PLSS  grid  and  applying  footage  calls 
from  the  PI  file.   Before  the  data  could  be  processed  with  GGWL,  however,  the 
file  had  to  be  reformatted.   The  attributes  for  each  well,  other  than  a  well 
identification  number,  were  removed  and  placed  in  a  separate  text  file  using 
the  SORT/MERGE  utility,  after  which  the  GGWL  program  was  executed. 
Coordinates  for  300  wells  in  the  region  were  computed  in  about  an  hour 
producing  an  ADS  point  map  for  transfer  to  MOSS. 

The  file  of  remaining  well  attributes,  created  in  the  reformatting 
procedure,  was  used  to  create  a  multiple-attribute  file  in  MOSS  allowing  map 
items  to  be  selected  based  on  boolean  criteria.   Figure  10  displays  data  flow 
for  resource  information. 

2.  Problems,  Issues,  and  Solutions. 

Both  footage  calls  for  well  locations,  geographic  coordinates  were 
available  from  PI;  however,  locations  for  the  same  wells  varied.   To  assess 
the  quality  of  existing  and  computed  coordinates,  a  single  map  was  created 
showing  the  well  locations  from  both  sources.  (See  Figure  11  for  location 
data.)  The  resulting  map  was  compared  to  photogrammetrically  derived  well 
locations  and  PLSS  corner  positions.   The  coordinates  computed  using  GGWL 
proved  to  be  significantly  more  accurate. 

The  problem  of  nonstandard  ASCII  formats  again  was  flagged  again  in 
this  process.   The  PI  files  had  to  be  manipulated  to  make  them  DG/ASCII- 
compatible.   The  solutions  for  this  problem  were  the  same  as  those  cited  in 
the  earlier  descriptions  of  incompatible  ASCII  formats. 

The  data  had  to  be  reformatted  before  the  GGWL  program  could  be 
applied.   Again,  file  manipulation  (using  SORT/MERGE)  was  required  before 
processing  could  proceed.   Unfortunately,  this  required  manipulation  can  be 
unique  to  each  file,  limiting  the  application  of  the  SORT/MERGE  routines  to  be 
executed  in  a  macro  mode. 
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Figure  10   DataFlow  for  Resource  Information 
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Figur*     11        PI     L«aa3»     for     W«ils 


The  PI  data  had  a  number  of  missing  records  that  required  "dummy" 
records  to  be  inserted,  again  requiring  manual  manipulation.   The  GGWL  program 
should  be  modified  to  handle  PI  input  file  record  problems. 

3.   Recommendations . 

The  ASCII  standard  provided  on  the  PI  tape  and  the  DG  ASCII  standard 
were  not  compatible.   The  adoption  and  use  of  standard  ASCII  formats  would 
eliminate  or  significantly  reduce  the  problem  of  reformatting. 

The  GGWL  program  cannot  handle  PI  files  with  missing  records.   The 
records  must  be  manually  inserted  before  the  program  can  be  run.   The  GGWL 
program  should  be  modified  to  accommodate  missing  records. 


USER  VIEWPOINT 


A.  CAPABILITIES 

Using  survey  methods  and  PCCS  has  significant  advantages  over  digitizing 
methods  because  of  improved  accuracy  of  coordinate  locations  and  quality 
control  checks  for  survey  data.   The  digitizing  method  requires  significantly 
less  capital  investment  to  collect  information,  but  potential  data 
inaccuracies  could  lead  eventually  to  significant  costs  related  to  lawsuits  or 
loss  of  royalties. 

Macros  were  written  to  simplify  the  user  interface  for  processing  data. 
These  macros  provided  the  users  with  a  set  of  menus  from  which  a  number  of 
options  could  be  selected  to  perform  specific  tasks.   Although  GIS  programs  or 
commands  were  used,  they  required  no  GIS  training  to  execute. 

The  Tektronix  4111  graphics  terminal  provided  good  facilities  for 
examining,  displaying,  and  working  with  geographic  data.   This  terminal  is 
much  improved  over  the  equipment  currently  being  used  by  other  Bureau  field 
offices. 

B.  ISSUES  AND  PROBLEMS 

Not  enough  time  was  allowed  for  developing  the  macros  or  programs 
required  to  manipulate  the  alphanumeric  data  base.   These  programs,  however, 
would  have  required  a  significant  effort  to  develop.   An  RDBMS  would  have 
satisfied  most  of  these  requirements  and  would  have  reduced  the  time  needed  to 
handle  all  information. 

Macros  demonstrated  the  need  for  a  more  simplified  user-machine  interface 
if  LIS  capabilities  are  to  be  implemented  in  field  offices.  Additionally, 
Resource  Area  personnel  did  express  the  need  for  more  flexibility  in  using  the 
system,  a  capability  that  the  macros  did  not  provide.  The  macros  were  written 
in  the  language  of  a  nonstandard  operating  system  and  thus  can  only  be  used  on 
DG  computers  that  execute  AOS. 


The  quality  of  data  was  cited  as  a  major,  potential  problem.   Some  of  the 
data  were  inaccurate,  inconsistent,  or  simply  not  available  for  this  project. 
Geographic  locations  of  wells  proved  to  be  inconsistent  when  retrieved 
directly  from  the  latitude/ longitude  coordinates  and  computed  than  legal 
descriptions.   Figure  12  shows  the  locational  differences  of  wells  that  were 
common  throughout  the  PI  data  file.   (Note  that  latitude/longitude  locations 
tend  to  be  systematically  displaced  to  the  southwest.)   By  comparing  these 
locations  with  well  maps  derived  from  photogrammetric  placement,  the 
coordinates  generated  from  legal  descriptions  (footage  calls  from  the  section 
line)  proved  to  be  more  accurate.   The  accuracy  of  these  locations,  however, 
resulted  from  highly  accurate  land  surveys  throughout  the  study  area.   This 
may  not  be  the  case  in  other  study  areas.   Additionally,  not  all  the  wells  had 
legal  descriptions,  creating  an  incomplete  locational  data  base  when  only 
legal  descriptions  were  used. 

Data  were  also  a  concern  when  plotting  the  maps  derived  from  Case 
Recordation  legal  descriptions,  with  one  active  lease  was  not  available  in  the 
data  base.   Resource  Area  personnel  emphasized  the  need  to  have  a  complete 
data  base  that  is  accurate  and  up-to-date. 

Locations  of  section  boundaries  varied  according  to  source.   The 
locations  of  digitized  coordinates  and  coordinates  computed  with  PCCS  compared 
favorably  for  most  of  the  study  area,  but  isolated  cases  revealed  significant 
differences.   Figure  13  shows  an  example  of  locational  differences  between  the 
two  sources  in  T22N,  R6W.   The  coordinates  produced  with  PCCS  were  more 
accurate  than  digitized  coordinates,  given  their  original  sources  and 
systematic  errors  propagated  through  the  digitizing  process.   The  generic 
township  coordinates  were  less  accurate  and  were  not  compared,  but  proved 
useful  for  testing  software  and  producing  sample  products. 

Additionally,  USGS  7  1/2-minute  quads  seldom  portray  the  location  of  any 
coordinates  in  the  land  net,  other  than  section  corners.   Survey  data  include 
all  coordinates  that  affect  the  location  of  section  boundaries.   Therefore, 
section  boundaries  that  change  direction  at  a  quarter  corner  are  seldom 
captured  in  the  process  of  digitizing,  but  are  accounted  for  with  PCCS. 
Figure  14  displays  the  kinds  of  differences  that  could  result  from  similar 
situations. 

C.    RECOMMENDATIONS 

Since  the  capabilities  demonstrated  and  used  as  part  of  this 
demonstration  are,  for  the  most  part,  available  on  existing  MOSS/ADS-based  CIS 
systems  in  the  Bureau,  the  Bureau  should  continue  to  use  these  systems  to 
assist  with  accomplishing  field  tasks.   Macros  demonstrated  the  potential  for 
improved  user-machine  interface  of  current  CIS  capabilities.   However,  the 
Bureau  should  not  pursue  the  development  of  additional  macros  on  DG 
equipment.   The  Tektronix  terminal  greatly  improved  the  user's  ability  to 
examine  and  display  graphic  data  and  enhanced  the  user  interface  to  the 
system.   Existing  graphics  terminals  currently  being  used  for  GIS  should  be 
examined  for  replacement,  since  many  issues,  such  as  the  amount  of  time 
required  to  plot  maps,  can  more  easily  be  addressed  by  hardware  than  software. 
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Figura     12        Exampla     of     Loeational     Varianeas     on     PI     Data 
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Figur*     13        Loeatlonal     Diff«r«nc«o     In     Coordinates     computed 
with     PCCS     and     Digitized     from     a     7      1/2     minute     quad 
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Data  and  the  management  of  data  should  also  be  addressed.  Attempts 
should  be  made  to  improve  the  quality  of  existing  data  and  to  standardize 
coding,  accuracy,  and  transfer  procedures.   Serious  consideration  needs  to  be 
given  to  PI  data  and  to  Case  Recordation.   Capabilities  for  updating  and 
quality  control  were  specified  as  needed  improvements.   To  enhance  the 
capability,  the  Bureau  should  examine  the  potential  interim  applications  of  an 
RDBMS . 


CONCLUSION 


This  project  not  only  identified  major  problem  areas  for  implementing  LIS 
Bureauwide  but  demonstrated  the  potential  benefits  of  such  a  system.   All  of 
the  information  provided  as  a  result  of  this  project  will  help  the  Bureau  move 
toward  full  implementation  of  LIS  in  the  1990s. 

Because  the  demonstrated  capabilities  did  not  include  an  RDBMS,  the 
system  had  limited  flexibility  in  analyzing  alphanumeric  data.   Much  of  the 
data  used  for  analysis,  such  as  resource  values  or  case  data,  was  in  an 
alphanumeric  format.   Currently,  data  must  be  stored  in  attribute  files  which 
are  more  cumbersome  to  use.  Without  an  RDBMS,  along  with  a  Data  Base 
Administrator,  sort  and  retrieval  of  this  data  proved  time-consuming. 

Perhaps  the  most  significant  problems  associated  with  implementing  LIS 
center  around  data  standards  and  data  quality/availability.   Eight  of  the  10 
months  spent  on  the  project  were  devoted  to  identifying  data  requirements  and 
converting  the  data  files  to  a  standard  format.   Additionally,  only  a  few  BLM 
offices  have  all  the  ALMRS-GIS  data  required  for  effective  decision  making 
based  on  LIS  products.   More  importantly,  each  office  would  need  to  convert 
much  of  its  data  to  a  standard  format,  which  would  require  a  significant 
effort. 

The  Redline  Phase  of  the  Farraington  Project  demonstrates  the  benefits  of 
automation.   One  comparison  was  made  between  the  performance  of  the  project  and 
the  performance  of  the  Bureau's  present  digitizing  system.   Capabilities  used 
in  the  project  required  90  percent  less  time  to  capture  data  themes  than  the 
present  digitizing  system.   This  efficiency  is  gained  however  only  if  data 
exists  in  a  standard  format. 

The  project  identified  and  documented  the  need  for  an  improved 
user-machine  interface.   The  benefits  of  a  simplified  user  interface  were  also 
demonstrated  along  with  data  as  the  major  criteria  for  BLM  field  acceptance. 

With  the  capabilities  demonstrated  in  this  project,  the  Bureau  can  begin 
to  develop  a  linked  data  base  containing  record  and  resource  information  that 
tie  to  positions  on  the  earth  in  an  automated  manner.   Since  digitizing  is 
avoided  for  records  data,  significant  amounts  of  time  and  money  are  saved  in 
creating  and  maintaining  the  data  base.   The  Bureauwide  applicability  of  a 
system  that  allows  for  the  efficient  use  of  heterogenous,  but  spatially 
related  data  are  readily  apparent.   A  system  that  gives  quicker,  more  accurate 
analyses  would  allow  the  resource  specialists  more  time  in  the  field, 
resulting  in  more  effective  management  of  public  lands. 
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ABSTRACT 

This  paper  describes  the  implementation  of  an  enhancement  to  AMS  that 
allows  subsetting  and  overlaying  of  polygons  and  displaying  the  results.  The 
capabilities,  user  interface,  algorithms,  and  program  structure  of  the 
implementation  are  discussed,  along  with  problems  encountered  in  interfacing  to 
existing  code  and  data  structures.  Also  described  are  the  software  engineering 
principles  and  strategies  used  in  the  design  and  implementation  of  this  system. 

INTRODUCTION 

This  paper  describes  the  design  and  implementation  of  an  arc  node  overlay 
subsystem  of  AMS  that  is  being  developed  by  DBA  Systems,  Inc.  for  the  U.S. 
Army  Engineer  and  Topographic  Laboratories  (USAETL)  at  Fort  Bel  voir,  Virginia. 
DBA  is  currently  supporting  UNIX  and  VMS  versions  of  AMS,  MOSS,  and  MAPS  for 
USAETL,  and  has  been  requested  to  develop  overlay  capabilities  in  AMS.  The 
target  system  was  originally  an  HP  9030  minicomputer  running  UNIX,  however,  the 
project  was  subsequently  redirected  to  a  VAX/750  running  the  VMS  operating 
system  and  eventually  will  be  ported  to  a  Micro  VAX  II. 

In  general,  an  overlay  processor  combines  two  or  more  maps  of  the  same 
geographic  area  that  represent  different  categories  or  themes  of  surface 
features.  For  example,  a  map  of  the  soil  of  a  particular  region  may  be  combined 
with  a  map  of  the  flood  potential  of  the  same  region  to  find  areas  subject  to 
soil  erosion.  An  overlay  processor  performs  set  operations  to  determine  the 
union,  intersection  or  difference  of  features  depicted  on  two  or  more  maps 
separates  or  overlays.  Figures  1,  2,  and  3  show  examples  of  each  operation. 

Currently,  the  MAPS  portion  of  the  MOSS  family  allows  overlay  of  raster 
data,  and  the  MOSS  program  supports  the  overlay  of  vector  polygon  data.  The 
primary  motivation  for  the  new  overlay  processor  is  to  remove  the  limitations  on 
the  size  of  the  overlays  that  can  be  performed  with  the  existing  MOSS  software. 
In  addition,  the  overlay  algorithm  used  in  MOSS  is  relatively  inefficient  with 
respect  to  processing  time.  This  can  be  shown  by  the  following  proportion: 


T  cc  N5 


where  T  is  time 
and  N  is  the  number 
of  1 ines  segments 
to  be  compared. 
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The  new  overlay  processor  uses  a  more  sophisticated  algorithm  which  should 
improve  performance  (Guevara  1986).  Processing  time  for  the  new  AMS  overlay 
processor  can  be  represented  by: 

T  oc  N  Log  N 

USAETL  also  determined  that  output  to  an  arc  node  format  was  more  convenient 
than  the  polygon  format  of  the  data  in  MOSS.  Thus,  the  new  program  should  be  a 
part  of  AMS,  where  the  data  is  already  in  an  arc  node  format. 


CAPABILITIES 


A  view  of  the  master  menu  provides  a  good  starting  point  for  a  discussi 
of  the  capabilities  required  by  USAETL.  (See  Figure  4) 
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The  "working  defaults"  for  the  current  session  are  shown  at  the  top  of  the 
screen.  This  information  is  saved  between  sessions,  and  may  be  updated  by 
choosing  one  of  the  menu  options  5  through  8.  Option  2,  allows  a  user  to  select 
a  set  of  themes  as  candidates  for  overlay.  A  user  may  also  work  with  a  subset 
of  the  attributes  in  a  theme  by  selecting  a  set  of  attributes  or  excluding  a  set 
of  attributes. 

Option  3  allows  a  user  to  enter  an  overlay  expression  using  any  of  the 
themes  selected  under  option  2,  and  any  of  the  three  operators.  A  typical 
overlay  expression  would  be 

A  -  (B  I  C) 

which  translates  to  "find  all  of  the  area  containing  attributes  from  map  A  but 
not  containing  any  of  the  area  covered  by  B  or  C". 

■  Option  4,  allows  the  user  to  display  the  job  file  after  the  overlay  has 
been  performed  and  to  selectively  display  polygons  with  certain  attributes.  The 
user  may  also  point  to  a  displayed  polygon  with  the  cursor  and  obtain  the 
attributes  of  that  polygon. 

ALGORITHMS 

Two  papers  that  provide  surveys  of  algorithms  in  current  use  in  GIS, 
Aronson  (1982)  and  Guevara  (1984),  were  reviewed  during  the  design  phase  of  the 
project.  Among  the  algorithms  described  are  the  ones  in  use  by  ANOTB,  OVER, 
WHIRLPOOL,  and  MOSS.  The  algorithm  in  use  in  the  WHIRLPOOL  system  is  the  only 
one  that  gives  a  theoretical  performance  of  N  Log  N  rather  than  an  N  squared 
performance.  Thus,  this  algorithm  was  the  obvious  choice  for  our  system. 

The  heart  of  the  algorithm  is  to  find  the  lines  of  the  two  maps  that 
intersect.  The  WHIRLPOOL  algorithms  looks  for  intersections  of  chains  of  line 
segments  and  then  does  an  operation  similar  to  a  binary  search  to  look  for  the 
intersection  of  lines.  The  implementation  developed  by  DBA  in  the  new  system 
looks  for  the  intersection  of  line  segments  directly.  This  simplifies  the 
coding  considerably  and  makes  the  line  intersection  algorithm  relatively 
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AMS  ARCNODE  OVERLAY  PROCESSING 

CURRENT  DEFAULTS 

PROJECT:  NEWJ 

GEOUNIT  CENTER:  39.27,38  -74,32,30 

WORKING  BOUNDARY: 

NE  CORNER:  41.00,16  -73,00,00 

SW  CORNER:  37,55,00  -76,05,00 

OVERLAY  PROCESSING  MENU 

1.0    EXIT 

2.0  SELECT  THEMES  TO  OVERLAY 

3.0  DO  OVERLAYS 

4.0    DISPLAY  /  ANALYSIS 

5.0    CHANGE  PROJECT 

6.0    CHANGE  GEOUNIT 

7.0    CHANGE  WORKING  BOUNDARY  (INPUT  COORDINATES) 

8.0    CHANGE  WORKING  BOUNDARY  (SELECT  WITH  CURSOR) 
ENTER  MENU  SELECTION  [1]  :  10 
Enter  a  number  between  1  and  8  (Press  RETURN  to  re-enter)  :_ 


Figure  4.  Master  Menu 


efficient.  After  the  line  intersections  are  found,  a  pass  is  made  through  the 
polygons  to  concatenate  the  attributes  of  the  lines  of  polygons  involved  in 
intersections.  Another  pass  is  made  through  the  polygons  to  look  for  islands 
and  to  make  further  adjustments  to  the  attributes.  Finally  the  resultant  maps 
are  combined  and  written  to  an  AMS  job  file. 

The  line  intersection  algorithm  can  be  understood  intuitively  by  imagining 
the  two  maps  to  be  side  by  side  as  shown  in  Figure  5.  A  horizontal  bar  sweeps 
up  through  the  two  maps.  Whenever  the  bar  crosses  the  bottom  of  a  line,  that 
line  is  added  to  a  list  to  be  tested  for  intersection.  Whenever  the  bar  crosses 
the  top  of  a  line,  that  line  is  removed  from  the  list  being  compared  for 
intersections.  This  way  we  do  not  have  to  test  every  line  against  every  other 
line  for  a  possible  intersection,  but  only  those  lines  in  a  narrow  band  moving 
up  the  map.  In  the  above  example  lines  1,  7,  and  A  have  all  been  processed.  As 
the  bar  continues  to  move  upward,  line  C  will  next  be  added  to  the  "Short  List" 
on  the  right  and  check  against  lines  2  and  6  for  intersection. 

DESIGN   CONSIDERATIONS 

The  goals  of  the  design  were  to  produce  a  high  performance  system  that  can 
be  easily  maintained  and  ported  to  other  computers  and  operating  systems  with 
minimal  effort.  The  ability  to  port  to  another  computer  has  already  been  useful 
because  of  the  redirection  of  the  project  from  implementation  on  the  HP-UNIX 
system  to  implementation  on  a  VAX/VMS  system. 

Within  the  last  few  years  the  language  C  has  become  available  in  a  standard 
form  on  most  computers  and  has  thus  become  an  alternative  to  FORTRAN  for 
scientific  software  systems.  The  tools  provided  by  C  for  isolation  of  the 
parameters  that  control  the  size  of  the  problem  that  can  be  solved,  and  C 
constructs  that  assist  in  writing  structured,  modular  code  made  it  the  language 
of  choice  for  the  overlay  processor.  A  more  technical  discussion  of  the 
advantages  of  C  is  found  in  the  section  on  implementation  details, 

USER   INTERFACE 

The  new  interface  implemented  with  this  system  is  similar  to  the  old  in 
that  options  are  presented  in  menu  format  and  the  user  responds  to  prompts.  Also 
the  user  may  select  a  default  option  appearing  within  brackets  on  the  prompt 
line  by  pressing  return.  However,  the  introduction  of  a  few  simple  screen 
handling  primitives  and  the  addition  of  a  few  conventions  have  improved  the 
appearance.  The  master  menu  displayed  in  figure  4  illustrates  the  conventions 
adopted.  The  display  shows  the  master  menu  after  the  user  has  selected  option 
"10",  which  is  invalid. 

The  screen  handling  routines  divide  the  screen  into  four  parts.  The  top 
part  of  the  screen  is  a  display  area  that  shows  current  selections  or  other 
system  states.  The  next  section  of  the  screen  is  used  for  menus  or  detailed 
instructions.  The  second  line  from  the  bottom  is  reserved  for  messages  (such  as 
progress  reports)  and  prompts.  The  bottom  line  on  the  screen  is  reserved  for 
error  messages. 
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DESIGN   PHILOSOPHY 

For  years,  system  designers  have  been  using  a  top  down  approach  to  handle 
the  complexity  of  large  programming  systems.  In  this  approach  a  program  is 
broken  down  into  a  small  number  of  steps.  Then  the  steps  are  further  broken 
down,  until  the  lowest  set  of  steps  can  be  easily  implemented  in  a  prograraning 
language.  Each  step  then  becomes  a  subroutine  in  the  implementation.  A 
deficiency  of  this  design  technique  is  that  it  ignores  the  role  of  the  data  in 
the  system.  Thus,  the  data  passed  to  step  3  from  step  1  and  step  2,  for 
example,  may  consist  of  a  large  number  of  items  which  involve  complicated 
intersections  among  themselves.  Object  Oriented  design  grew  out  of  a  need  to 
manage  the  complexity  of  data. 

Object  Oriented  Programming  ideas  first  appeared  in  the  language  SIMULA  and 
reached  a  full  implementation  in  Smalltalk.  An  "object"  is  a  data  entity  and 
the  operations  that  can  be  performed  on  that  entity.  A  program  invokes  an 
operation  of  an  object  by  sending  an  object  a  "message".  A  programmer  can 
define  "classes"  of  objects,  and  subclasses  can  be  defined  that  "inherit" 
attributes  and  methods  of  the  superclass. 

In  a  strict  sense,  newer  languages  such  as  Ada  ,  and  Modula-2  are  not 
object  oriented  languages  in  the  Smalltalk  style.  However,  the  definition  of 
Object  Oriented  Programming  has  evolved  to  mean  a  design  and  implementation 
methodology  that  uses  the  concept  of  objects  as  a  means  of  handling  the 
complexity  of  large  programming  systems.  In  this  methodology  a  program  module 
represents  an  object  or  class  of  objects.  All  knowledge  of  the  internal 
structure  of  the  object's  data  should  be  limited  to  this  module.  This  technique 
is  often  called  "enforcing  the  abstraction".  Thus,  in  object  oriented  design, 
data  moves  through  the  system  in  large  "chunks"  whose  internal  structure  can  not 
be  manipulated  except  in  well  defined  ways  by  an  isolated  group  of  procedures. 

The  high  level  objects  chosen  for- the  implementation  of  this  project 
include  "Projects",  "Geounits",  "Themes",  "Attributes",  and  "Maps".  The 
operations  on  these  objects  include  "Selection",  "Graphing",  and  "Overlaying". 

The  programming  language  in  which  a  designer  thinks  has  a  powerful 
influence  on  the  design  of  a  software  system.  Thus,  a  language  that  allows  and, 
as  much  as  possible,  enforces  good  software  engineering  principals  should  be 
used  in  the  design.  For  this  reason  the  detailed  design  of  the  Overlay  System 
is  in  the  form  of  Modula-2  used  as  a  program  design  language  (PDL).  A  PDL  gives 
a  precise  algorithmic  description  of  a  system  that  is  easy  to  convert  into  code. 

Using  Modula-2  as  a  PDL  provides  a  number  of  advantages  over  writing  the 
code  directly  in  an  older  language.  First,  Modula-2  has  a  simple,  easy  to  read 
syntax  and  like  most  modern  programming  languages,  Modula-2  provides  powerful 
data  type  definition  facilities  and  control  structures  that  allow  structured 
programming.  Modula-2  provides  for  long  variable  names.  Thus,  variable  names 
can  be  self  descriptive.  Procedures  can  be  grouped  into  modules,  with  each 
module  having  its  own  local  data  typed  and  procedures.  This  grouping  can  make 
the  logical  structure  of  a  system  easier  to  understand,  and  provides  for 
implementing  information  hiding.  Modula--2  also  provides  for  separating  a 
module's  definition  part  from  its  implementation  part.  This  makes  the 
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difference  between  the  purpose  of  a  module  and  its  implementation  very  clear, 
thus  providing  a  programmer  with  information  on  what  parts  of  a  module  can  be 
modified  without  affecting  other  parts  of  the  system.  In  addition,  Modula-2 
requires  that  a  module  using  a  procedure  or  data  type  defined  in  a  lower  level 
module  must  implicitly  import  the  procedure  or  data  type  with  an  "IMPORT" 
statement.  This  provides  excellent  documentation  of  the  resources  used  by  a 
module.  When  complied,  Modula-2  provides  strong  type  checking  across  procedure 
interfaces.  This  checking  of  the  consistency  of  the  system  can  detect  many 
logic  errors  that  might  otherwise  escape  detection. 

IMPLEMENTATION   DETAILS 

When  integrating  a  software  subsystem  into  a  larger  system,  a  number  of 
decisions  must  be  made.  For  example:  What  parts  of  the  existing  code  can  be 
re-used?  How  much  compatibility  with  the  existing  user  interface  should  be 
maintained?  Should  the  new  code  follow  the  style  and  structure  of  the  old? 

A  number  of  problems  were  seen  in  re-using  or  significantly  modifying 
existing  code.  While  much  of  the  code  is  very  good,  large  portions  of  the  code 
do  not  adhere  to  such  common  software  engineering  principles  as  structured 
programming,  or  indentation  of  the  code  in  loops  to  reflect  structure.  One  of 
the  biggest  problems  with  using  existing  modules  is  the  extensive  use  of  FORTRAN 
common  data  variable  which  hide  (or  destroy)  any  hierarchial  structure  of  the 
data  flow  and  makes  use  of  a  single  module  from  the  system  difficult.  Although 
the  code  is  compatible  with  FORTRAN  77,  most  of  the  code  uses  the  FORTRAN  66 
style,  so  that  IF-THEN-ELSE  constructs,  parameter  statements,  and  CHARACTER 
variables  are  seldom  used. 

The  conclusion  reached  in  the  design  of  this  project  was  that  it  was  much 
easier  and  less  expensive  to  write  the  entire  overlay  system  from  scratch  than 
to  use  any  existing  code.  The  overlay  program  is  initiated  from  the  master  AMS 
menu,  operates  on  the  same  data  files,  uses  the  same  graphics  libraries,  and  has 
a  similar  user  interface,  but  in  every  other  way  is  a  new  system. 

The  sophisticated  algorithms  needed  for  efficient  implementation  of  arc 
node  overlay  required  correspondingly  sophisticated  data  and  program  structures. 
Thus,  the  language  C  was  chosen  over  FORTRAN  as  the  implementation  language, 
primarily  because  of  FORTRAN'S  lack  of  data  structures,  and  inability  to  handle 
recursion,  which  is  used  in  some  of  the  algorithms.  The  wider  variety  of 
control  structures  available  in  C  also  assist  in  using  structured  programming 
techniques.  Another  advantage  is  that  all  of  the  Modula-2  used  in  the  design 
can  be  directly  translated  into  C  constructs. 

C  provides  an  "#include"  statement  that  includes  text  from  another  file 
before  compilation.  This  feature  allows  us  to  emulate  the  import  of  data  types 
available  in  Modula-2  and  used  in  the  PDL.  All  data  type  definitions  used  in 
more  than  one  file  are  defined  in  a  separate  "h"  file  and  included  in  the  source 
code  files  that  need  them.  This  means  that  these  definitions  appear  in  only  one 
place,  which  simplifies  changing  them  and  eliminates  the  possibilities  of 
different  definitions  in  different  programs. 

In  order  to  make  the  system  more  protable,  the  operating  system  and  device 
dependent  features  were  isolated  into  three  main  modules.  The  procedures  to 
create  directory/file  names,  get  system  error  messages,  and  do  any  system 


dependent  initialization  are  located  in  the  module  LowLevSys.     Any  future 
routines  that  depend  on  word  size,  byte  order,  etc.   (none  were  used  in  the 
current  implementation)  would  also  be  included  in  this  module.     The  graphics 
primitives  are  located  in  module  LowLevGrph.     Screen  handling  routines  (clear 
the  screen,  move  the  cursor,  print  a  line,  etc.)  are  located  in  the  module 
LowLevScr.     Fancy  screen  handling  was  avoided,  thus  allowing  a  few  easily 
implemented  routines  to  suffice.     The  remainder  of  the  code  should  work  on  any 
computer  with  a  C  compiler  which  implements  the  buffed  C  I/O  routines  fopen, 
fread,  fwrite,  fclose,  and  fseek  (most  do).     If  the  I/O  routines  are  not 
available,  then  they  can  be  implemented  (with  the  same  names  and  call   sequences, 
so  that  the  main  code  need  not  change)  using  the  resources  of  that  computer. 

All  constraints  on  array  sizes,  stack  limits,  etc.   in  the  system  were 
parameterized  with  "#define"  statements  in  an   include  file,  SysLimits.h.     An 
attempt  was  made  to  have  all   procedures  check  on  array  overflow  and  to  print  an 
error  message  detailing  the  routine  and  the  parameter  that  was  exceeded.     This 
should  make  it  easier  to  tune  and  adjust  the  program  or  to  increase  the  size  of 
the  problem  that  can  be  solved- 

DOCUMENTATION 

Documentation  should  not  be  left  as  an  afterthought  in  system  design  and 
implementation,  and   it  was  not  in  this  system.     An  updated  version  of  the 
requirements  document  will   become  the  users  manual   for  the  system.     The  high 
level   and  detailed  design  documents  should  provide  excellent  programmer 
documentation.     Good  documentation  is  a  product  of  a  detailed  and  thorough 
design. 

CONCLUSIONS 

DBA  Systems  will   deliver  to  USAETL  an  overlay  processor  which  will   be  able 
to  efficiently  solve  larger  problems  than  the  current  MOSS  overlay  capabilities. 
The  new  overlay  processor  will   be  easier  to  maintain  and  adjust,  due  to 
parameterization  of  systems  limits,  and  a  modular,  structured  design. 

We  believe  that  major  modification  and  additions  to  the  MOSS  program  family 
are  simplified  by  adoption  a  "parallel   system"  strategy.     That  is,  writing  a 
subsystem  that  uses  the  existing  data  files  and  appears  to  the  user  as  part  of 
the  same  system,  but  does  not  attempt  to  re-use  or  interact  with  any  of  the 
existing  code.     This  allows  the  system  designer  to  use  modern  languages  and 
software  engineering  techniques. 
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MOSS  Display:  COS  to  C0S3 
Anne  T.  Hunter 
Autometric,  Inc. 


INTRODUCTION 


During  the  mid  70 's,  development  of  the  MOSS  family  of  software  began 
to  take  place.  The  Automated  Mapping  System  (AMS)  was  developed  to, 
enter  geographical  data,  while  the  Map  Overlay  and  Statistical  System 
(MOSS)  and  the  Map  Analysis  Processing  System  (MAPS)  were  developed  to 
display  and  analyze  geographical  data.  During  preliminary  use  of  these 
packages,  it  became  clear  that  a  hardcopy  output  system  was  also 
needed,  thus  the  development  of  the  Cartographic  Output  System  (COS) 
began.  The  driving  force  behind  the  Cartographic  Output  System  was 
the  need  for  hardcopy  output  of  MOSS  products  as  well  as  cartographic 
production.  The  main  purpose  of  COS  was  to  allow  non-technical  users 
to  produce  high  quality  cartographic  products  in  a  relatively  simple 
and  efficient  manner.  COS  software  as  other  software  of  the  MOSS 
family,  has  continued  to  evolve  over  the  years.  The  subject  of  this 
paper  is  to  introduce  an  entirely  new  version  the  Cartographic  Output 
System,  namely  C0S3 . 

C0S3  was  developed  out  of  the  need  for  a  faster,  more  effcient  output 
system.  Development  began  around  1983,  subsided  for  over  a  year,  and 
resumed  again  in  1985.  This  new  version  of  the  COS  is  an  entirely  new 
software  package,  not  an  updated  version  of  existing  COS  software. 
COS  and  C0S3  do,  however,  share  some  functionalities  as  well  as  the 
same  basic  concept  of  graphic  construction.  The  end  product  of  either 
system  is  the  same,  a  high  quality  cartographic  hardcopy.  The  manner 
in  which  the  final  product  is  reached  differs  between  the  two  systems. 

BASICS  OF  ANY  CARTOGRAPHIC  OUTPUT  SYSTEM 


COS  and  C0S3  have  4  basic  functions:    1)  graphic  construction,   2 


A 


graphic  editing,  3)  graphic  display,  and  4)  database  maintenance, 
graphic  can  be  defined  as  the  desired  final  product.  COS  and  C0S3 
share  the  basic  terms  involved  with  graphic  construction.  The  final 
product  of  either  system  is  called  a  profile.  The  parts  of  the  final 
product  -  map,  barscale,  grid,  etc.  -  are  called  components.  The 
components  are  composed  of  text,  lines,  markers,  shading  which  are 
called  primitives.  Construction  of  a  final  product  actu.ally  begins 
when  primitives  which  are  placed  together  to  construct  components. 
Components  are  placed  together  to  create  a  profile  or  final  product. 

I     This  is  the  way  in  which  both  COS  and  C0S3  approach  creating  a  final 
product . 


IMPROVEMENTS  OF  C0S3 

C0S3  was  developed  to  allow  production  of  hardcopy  outputs  easier  and 
more  efficient.  Three  of  the  major  improvements  are  the  user 
interface,  use  of  a  stroke  device  and  automation  of  rudimentary  tasks. 


User  Interface 

The  COS  command  structure  consists  entirely  of  menus.  There  is  a 
command  mode  in  COS,  but  it  is  very  limited.  The  C0S3  interface  is 
entirely  command  driven  and  is  very  similar  to  the  MAPS  user 
interface.  Some  prompting  does  occur,  but  for  the  most  part  the 
command  and  necessary  phrases  are  required.  Having  a  command  driven 
as  opposed  to  a  menu  driven  system  has  implications  throughout  the 
entire  system.  The  number  of  steps  and  the  time  involved  with 
constructing,  displaying  or  editing  a  graphic  is  shortened 
considerably  with  C0S3  simply  because  of  its  command  driven  interface. 
Figure  1  illustrates  this  point  by  comparing  the  steps  necessary  for 
constructing  and  displaying  a  grid  in  COS  and  C0S3. 

Stroke  Device 

A  second  improvement  is  the  implementation  of  a  stroke  device.  The 
stroke  device  or  graphics  cursor  can  be  used  to  enter  primitives  into 
a  component,  place  primitives  and  components,  and  to  edit  components 
and  profiles.  This  makes  construction  and  editing  of  components  and 
profiles  easier  and  more  efficient. 

Automation  of  Rudimentary  Tasks 

A  third  improvement  involves  automation  of  tasks  that  are  commonly 
performed  throughout  construction  of  a  graphic.  Read  files  and  bundle 
tables  have  been  implemented  to  accomplish  this.  A  read  file  is  very 
similar  to  a  macro  in  CLI  .  A  file  can  be  set  up  that  contains 
commands  that  are  frequently  performed  or  necessary  to  perform  in 
constructing  a  graphic.  C0S3  can  be  told  to  read  from  that  file  and 
the  commands  are  performed  accordingly.  Read  files  are  used  in 
creating  commonly  used  components  such  as  barscales,  legends,  grids, 
and  are  used  to  perform  other  necessary  tasks  such  as  setting  \xp  and 
selecting  the  normalization  transformation,  setting  the  input  and/or 
output  devices.  The  second  improvement  in  this  area  involves  the  use 
of  a  bundle  table.  All  the  primitives  (text,  line,  markers,  shade 
patterns)  carry  with  them  attributes.  For  example,  attributes  of  the 
text  primitive  include  character  height  and  width,  font  #,  and 
rotation.  Each  primitive  has  default  values  for  each  attribtite,  but 
these  values  can  be  changed  at  any  time.  The  bundle  table  facilitates 
changing  the  attribute  values  of  the  primitives  one  at  a  time,  a 
bundle  table  index  can  be  assigned  to  the  primitive.  The  attibute 
values  for  this  primitive  are  then  gotten  from  the  bundle  table. 
Essentially,  the  bundle  table  is  similar  to  a  large  default  table  of 
attribute  values.  Whenever  a  specific  group  of  values  is  desired,  the 
specific  index  of  the  bundle  table  is  addressed.  This  is  especially 
useful  when  creating  a  graphic  with  many  components  that  need  to  use 
the  same  attribute  values. 


Fig.    1 
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CONCLUSION 

There  are  several  functions  of  COS  that  have  been  carried  over  to 
C0S3.  For  example,  the  generation  of  a  log  file  when  creating  a  plot 
fie,  use  of  auxiliary  text  files,  and  scaling  of  a  graphic  at  the 
time  of  plotting.  C0S3  also  uses  the  same  line  and  text  fonts  and 
shade  patterns  as  COS  and  MOSS.  There  are  still  several  functions 
that  need  to  be  implemented  in  C0S3  such  as  the  ability  to  handle 
raster  and  AMS  data  as  well  as  existing  COS  data. 

A  technical  advantage  of  C0S3  is  its  use  of  the  Graphics  Kernal  System 
(GKS).    The  advantage  of  GKS  implementation  is  that  GKS  is  the 
standard   for   graphics   programming,   which   introduces   graphics 
flexibility  and  increases  its  portability  to  other  systems. 

In  conclusion,  the  COS  exists  among  the  MOSS  family  of  software  to 
produce  high  quality  cartographic  products.  C0S3,  the  latest  version 
of  the  COS,  has  been  developed  to  further  facilitate  the  production  of 
cartographic  products  by  simplyfying  the  procedures  involved  in 
producing  the  final  graphic. 


A  6KS  GRAPHICS  INTERFACE  FOR  MOSS  SOFTWARE 

Gerry  Rickers 

DBA  Systems,  Inc. 

11781  Lee  Jackson  Memorial   Hwy. 

Fairfax,  Virginia     22033 

ABSTRACT 

DBA  Systems,  Inc.,  under  contract  to  the  U.S.  Army  Engineer  Topographic 

Laboratories  (USAETL),  is  enhancing  the  AMS/MOSS  software  in  the  Terrain  Analyst 

Work  Station  (TAWS)  to  permit  graphic  operations  to  be  performed  by  software 
that  conforms  to  the  Graphical  Kernel  Standard  (GKS). 

With  over  1000  routines  in  the  Geographic  Information  Systems  (GIS),  it  was 
decided  to  implement  GKS  graphics  by  creating  a  library  of  conversion  routines 
that  will  satisfy  existing  calls  to  non-GKS  graphics  routines  by  subsequent 
calls  to  routines  in  Precision  Visuals'  GK-2000  software.  The  most  important 
aspect  of  this  development  has  been  the  design  of  an  interface  library  to 
emulate  current  cursor  positioning  and  to  ensure  data  integrity.  Current  cursor 
emulation  is  achieved  through  an  intersecting  workspace  that  relates  the  two 
graphics  standards  to  each  other.  Data  integrity  is  maintained  by  a  new  layer 
of  error  processing  software. 

A  benefit  of  this  enhancement  will  be  increased  device  independence  and 
portability  of  the  GIS  software,  which  will  be  able  to  operate  with  any 
peripheral  supported  by  the  GKS  graphics  software. 

INTRODUCTION 

DBA  Systems,  Inc.  is  currently  under  contract  to  provide  software 
maintenance  and  support  for  three  Geographic  Information  Systems  (GIS)  at  the 
U.S.  Army  Engineering  Topographical  Laboratories  (USAETL).  The  GIS  employed  at 
the  USAETL  consists  of  three  subsystems: 


*  Analytical  Mapping  System  (AMS), 

*  Map  Overlay  Statistical  System  (MOSS),  and 

*  Map  Analytical  Processing  System  (MAPS). 


Graphic  commands  to  the  HP  plotters  and  graphics  terminals,  rastertech 
graphics  terminals,  and  Digital  VT240  graphics  terminals  and  TEKTRONIX  graphics 
terminals  are  processed  by  DI-3000,  a  Core  Graphics  System  (CORE)  derivative. 
DI-3000  is  a  proprietary,  device,  independent  graphic  software  package  written 
and  supported  by  Precision  Visuals  Incorporated  (PVI).  The  DI-3000  graphic 
package,  although  a  device  independent  package,  does  not  rigorously  adhere  to  a 
nationally  recognized  standard  for  graphics.  Adherence  to  a  nationally  accepted 
standard  would  allow  for  greater  flexibility  and  portability  of  software.  As 
part  of  the  development  of  a  tactical  battlefield  GIS,  USAETL  decided  to 
implement  an  internationally  recognized  standard,  GKS  (a  Core  derivative),  which 
allows  greater  device  independence  than  DI-3000  and  a  wider  selection  of  vendor 
packages.  DBA  was  tasked  for  the  conversion  and  implementation  of  GKS  into  a 
VAX/VMS  version  of  the  GIS. 


PROJECT   ENVIRONMENT 

The  hardware  configuration  of  the  GIS  consists  of:  a  VAX  11/750  computer 
running  under  the  VAX/VMS  4.3  operating  system^  HP  plotter,  VT240  graphic 
terminal,  ALTEK  digitizer,  and  a  RASTERTECH  Model  ONE/10  terminal.  The  existing 
GIS  software  originated  from  an  HP-UX  operating  system  and  was  converted  to  the 
VAX/VMS.  Initially,  the  graphics  operations  were  performed  by  a  generic  graphic 
library.  Autograph,  which  provided  an  interface  to  the  DI-3000  graphic  package. 
The  graphic  calls  made  by  the  GIS  are  sent  to  the  generic  graphics  library  and 
are  then  passed  onto  the  DI-3000  library  of  the  actual  graphic  operation.  Error 
codes  within  the  GIS  during  graphic  operations  are  set  according  to  the  DI-3000 
error  codes. 

The  conversion  required  that  the  DI-3000  graphic  package  be  replaced  by  a  GKS 
graphic  package.  GK-2000,  a  GKS  package  developed  by  PVI  was  selected  for  use 
on  the  VAX/VMS  development  system.  The  only  limitation  of  GKS  is  that  the 
vendor  package  must  also  provide  the  I/O  driver  for  GKS  to  interface  with. 
This  limits  the  GKS  package  selected  to  only  the  devices  supported  by  the 
vendor.  Hereafter,  references  to  GKS  refer  specifically  to  GK-2000. 

The  conversion  effort  of  MOSS  DI-3000  graphics  to  GKS  requires  specific 
software  capabilities  to  be  in  place  within  the  GIS.  First,  the  existing  code 
that  properly  handles  error  conditions  from  the  graphic  interface  routines  must 
already  be  in  place.  The  new  code  being  developed  and  tested  for  the  conversion 
effort  has  its  own  layer  of  error  processing  and  without  this  first  assumption, 
further  definition  and  testing  of  the  existing  error  handling  code  would  need  to 
be  accomplished  to  assure  it  is  properly  functioning.  In  other  words,  during 
development  of  the  original  code,  thorough  testing  is  assumed  to  have  been 
completed  so  that  pre-existing  logical  errors  do  not  hinder  or  lengthen  the 
DI-3000  to  GKS  conversion  effort. 

Second,  GKS  does  not  support  three  dimensional  drawings;  therefore,  any 
requirements  for  three  dimensional  drawings  must  be  handled  by  low  level 
graphics  routines  as  part  of  the  graphic  subsystem.  The  current  GIS  three 
dimensional  display  capabilities  allow  a  three  dimensional  image  to  be  projected 
onto  a  two  dimensional  {x,y)  plane.  This  image  can  then  be  plotted  by  GKS, 
which  is  only  two  dimensional.  This  two  dimensional  restriction  is  a 
consideration  for  analysts  considering  a  conversion  to  GKS  because  it  will 
limit  or  change  the  requirements  for  future  development  of  applications  if  three 
dimensional  drawings  are  desired. 

Third,  no  specialized  device  features  can  be  present.  The  current  MOSS 
code  utilizes  some  escape  sequences  for  clearing  screens  or  positioning  cursors. 
The  use  of  escape  sequences,  which  are  device  dependent,  will  result  in  loss  of 
portability.  All  device  dependencies  must  be  identified  and  resolved  for  an 
effective  implementation  of  GKS. 


ALTERNATIVES 

Reviewing  the  task  of  converting  from  DI-3000  to  GK-2000,  DBA  evaluated  two 
different  approaches.     One  employs  an  interface  library  design,  such  as  the 
generic  graphic  library  already  in  place,  to  provide  an  intersecting  workspace 
in  which  to  convert  the  parameters  of  DI-3000  to  meet  the  parameter  requirements 
set  forth  of  the  newly  designated  GKS  package.     The  other  involves  coding  the 
necessary  parameter  changes  directly  into  the  source  code  required  for  the  new 
package. 

Option  one,  the  interface  library  design,  has  distinct  advantages.     With  an 
interface  library,  all   parameters  from  the  source  code  remain  unaltered,  thereby 
requiring  no  modifications  or  recompilations  of  the  source  code.     During  the 
testing  phase,  all   changes  made  to  convert  current  parameter  requirements  have 
taken  place  in  the  interface  library  delineating  where  an  error  might  occur  to 
one  routine  vice  several   routines.     If  changes  were  made  directly  into  the  code, 
as  mentioned  in  option  two,  a  logical   or  syntax  coding  error  relating  to  a 
graphic  call   discovered  in  one  routine  would  most  likely  require  changes  in  all 
routines  relating  to  the  same  graphic  operation.     Also,  within  the  interface 
library,  error  codes  of  GKS  calls  can  be  checked  independently  of  the  source 
code  error  handling  already  in  place.     If  an  error  does  occur  in  the  interface 
library,  affecting  operation  of  the  GIS  source  code,  an  appropriate  parameter 
can  be  set  and  returned  to  the  GIS  source  code  for  appropriate  handl ing 
according  to  previously  defined  error  handling  requirements. 

The  second  option  was  rejected  as  a  possible  approach  due  to  the 
considerable  amount  of  time  required  and  the  lack  of  flexibility.     For  option 
two  to  have  worked,  all   graphic  calls  within  the  source  code  would  need 
identifying  and  the  source  code  modificated  to  replace  all   calls  with  the  new 
parameter  requirements  of  the  newly  targeted  graphic  package.     With  over  1000 
routines  within  the  USAETL  GIS,  this  would  require  tremendous  maintenance  and 
recompiling  time  for  the  routines.     Also,  error  checking  was  currently  being  • 
done  in  accordance  to  the  existing  graphic   interface  package  error  codes  and  the 
targeted  GKS  graphic  package  did  not  always  conform  to  the  same  error  codes  for 
unsuccessful   events.     Hence,  complete  analysis  and  modification  of  error 
handling  code  within  existing  routines  to  properly  handle  unsuccessful   events 
would  be  required. 

DEVELOPMENT       PROCESS 

First,  all   DI-3000  calls  were  identified  along  with  parameter  requirements 
for  the  calls.     The  corresponding  GKS  functions  and  their  specific  parameter 
requirements  were  then  identified.     The  difference  between  the  parameter 
requirements  for  DI-3000  and  GKS  were  then  used  as  input  to  the  design  of  the 
interface  library  which  resolves  the  parameter  differences.     Figure  1  shows  the 
flow  of  the  data  from  the  GIS  source  code  into  the  intersecting  workspace  where 
the  parameter  requirements  are  made  compatible  to  GKS  and  then  passed  to  the 
actual   GKS  1 ibrary. 
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Figure  1.   Functional  Overview 
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The  second  step  of  the  requirements  was  to  identify  the  error  handling 
procedures  of  the  GIS  source  code.  The  data  gathered  from  this  portion  of  the 
requirements  was  then  implemented  in  the  design  of  the  interface  library  in 
which  GKS  errors  will  be  converted  to  meaningful  error  codes  of  the  GIS  source 
code.  All  calls  to  the  existing  generic  graphic  package  had  a  parameter  to 
handle  the  passing  of  error  codes  to  and  from  the  existing  library  and  this 
parameter  was  utilized  again  within  the  new  interface  library. 

Following  the  requirements  definition,  the  design  of  the  interface  library 
Was  started.  The  design  of  the  interface  library  consisted  of  the  following: 

*  Functional  description  of  the  subroutines  needed 

*  Inputs 

0   All  initializations  required  for  GKS 

0   All  device  initialization  required  for  the  GIS  source 

0   All  deinitial izations  for  GKS 

*  Outputs 

*  Processing  method 

0   Emulation  of  current  cursor  positioning 

0   Conversion  of  DI-3000  parameter  requirements  to  GKS  parameter 

requirements 
0   All  handling  of  GKS  error  codes  and  conversion  to  meaningful  GIS 

source  error  codes 

One  of  the  major  efforts  within  the  interface  library  design  was  to  handle 
the  relative  moves  and  draws  and  current  cursor  position  supported  by  DI-3000. 
GKS  does  not  support  the  process  of  current  cursor  position.  The  current  cursor 
position  is  emulated  in  the  interface  library  and  the  design  was  to  place  the 
emulated  current  cursor  position  in  a  common  block  for  access  by  the  other 
interface  library  routines.  Current  cursor  position  is  the  current  {x,y) 
coordinate  position  from  which  the  next  graphic  operation  is  to  be  performed, 
whether  a  draw  or  move.  Relative  moves  and  draws  are  used  to  draw  about  a  given 
current  cursor  position,  mostly  to  draw  diagrams  or  symbols  about  a  given  center 
or  starting  point.  Figure  2,  shows  the  concept  of  relative  moves  and  draws 
required  to  place  the  symbol  x  in  the  center  of  the  depicted  box,  and  the 
current  cursor  position  resulting  from  the  moves  and  draws.  The  box  is  depicted 
in  world  coordinates  and  the  moves  and  draws  are  given  in  world  coordinates. 
The  generalized  code  depicting  the  drawing  of  the  'x'  is  given  with  the  diagram. 
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The  first  move  depicts  a  move  in  absolute  world  coordinates  to  the  center 
of  the  box,  updating  the  current  position,  and  the  remaining  draws  and  moves  are 
depicted  as  relative  movement  about  the  current  cursor  position.  Relative  move 
and  draw  parameters  are  displacements,  in  world  coordinates,  about  the  current 
cursor  position.  Each  move  changes  the  absolute  current  cursor  position  to  the 
next  starting  point  for  the  next  graphic  operation.  As  mentioned,  GKS  does  not 
support  current  cursor  position.  For  DI-3000,  the  starting  {x,y)  coordinate 
pair  of  a  line  is  given  by  being  equivalent  to  the  current  cursor  position 
updated  by  either  a  move  or  draw  command.  When  a  line  is  drawn  in  DI-3000,  only 
the  ending  point  (x,y)  coordinate  needs  to  be  identified.  Figure  3,  depicts  the 
drawing  of  a  line  in  DI-3000  in  absolute  world  coordinates. 


FIGURE  3 


For  GKS  to  draw  the  same  line,  the  call  to  GKS  must  contain  both  the 
starting  and  ending  (x,y)  coordinate  pair.  To  do  this  the  interface  library  must 
emulates  the  current  cursor  position  so  that  a  starting  (x,y)  coordinate  is 
stored  globally  as  in  DI-3000.  After  initialization  of  GKS,  the  current  cursor 
position  is  (0,0).  Any  move  or  draw  subsequent  to  initialization,  updates  the 
current  cursor  position  and  variables  are  then  appropriately  updated  to  be  used 
as  the  starting  (x,y)  cursor  position  coordinate  pair  in  a  draw  for  GKS.  Figure 
4,  is  an  example  of  how  the  GIS  would  draw  a  simple  line  and  how  the  interface 
library  would  update  the  emulate  current  cursor  position  with  a  call  to  GKS  to 
finally  draw  the  line. 


FIGURE  4 


OUTPUT 


COMMANDS 


MOV.ABS  (2.  2) 
DRAW.ABS  (4.  4) 


(4,4) 


(0.0) 
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Figure  4.  Line  Draw  Using  Interface  Library  &  GKS 


The  first  section  shows  how  the  GIS  would  call  the  graphic  interface 
routine  to  move  to  a  starting  point  and  then  draw  a  line.  The  first  call  to  the 
routine  which  handles  moves  just  simply  updates  temporary  variables  emulating 
the  current  cursor  position  which  then  are  used  as  the  starting  (x,y)  coordinate 
for  a  line  draw.  No  call  to  the  6KS  library  is  necessary.  The  second  call  from 
the  GIS  to  the  actual  draw  gives  the  ending  (x,y)  coordinate.  The  starting  and 
ending  {x,y)  coordinate  pairs  are  then  loaded  into  a  two  dimensional  array  for 
GKS  format  with  {x(l),y(l))  equivalent  to  the  starting  point  and  {x(2),y(2)) 
equivalent  to  the  ending  point.  After  the  variables  are  then  updated  with  the 
ending  (x,y)  coordinate  pair  because  they  are  now  the  new  starting  point  for  the 
next  draw  or  move.  This  shows  that  the  current  cursor  position  from  relative 
and  absolute  moves  can  be  kept  and  then  reused  for  the  starting  point  for  the 
drawing  of  a  line.  It  is  essential  that  all  current  cursor  position  updates  are 
captured  and  the  temporary  variables  updated  appropriately  to  ensure  the  next 
call  to  a  line  draw  is  started  from  the  correct  (x,y)  coordinate. 

The  use  of  relative  moves  and  draws  was  depicted  earlier.  The  current  GIS 
software  for  USAETL  utilizes  the  relative  moves  and  draws  only  to  draw  the  symbol 
'x'  about  a  given  point.  The  GKS  software  supports  the  drawing  of  symbols.  By 
referencing  the  symbol  desired  and  calling  a  routine  to  draw  the  referenced 
symbol,  the  relative  moves  and  draws  within  the  GIS  could  be  removed.  It  is 
more  efficient  to  utilize  the  capabilities  of  GKS  to  draw  the  symbol  then  to  use 
relative  draws  and  moves. 

The  error  processing  built  into  the  interface  library  handles  the  error 
codes  returned  from  GKS  graphic  operations  and  converts  the  error  code  to  a 
meaningful  GIS  error  code.  This  requires  a  full  understanding  of  current  error 
handling  within  the  GIS  to  assure  the  GKS  error  code  is  transformed  to  an 
appropriate  GIS  code.  For  example,  the  GIS  code  might  have  predetermined  error 
codes  to  handle  specific  error  conditions.  If  a  graphic  operation  results  in 
one  of  the  predetermined  errors  after  a  GKS  graphic  operation,  the  returned 
error  code  from  the  GKS  operation  must  be  converted  such  that  it  is  a  meaningful 
error  code  when  returning  to  the  source  code.  Figure  5  depicts  an  example  of 
converting  an  error  code  returned  from  GKS  to  compatibility  with  the  GIS  code. 
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zero.  The  interface  library  then  proceeds  to  call  the  GKS  library  to  perform 
the  graphic  operation,  but  is  unable  to  complete  successfully.  The  error  code 
returned  from  the  GKS  library  is  equal  to  some  number  designating  specifically 
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the  error  incurred.  Upon  return  to  the  GIS  code, the  status  of  the  error  code  is 
checked  for  successful  completion,  which  in  this  instance  is  when  the  returned 
code  is  equal  to  one.  If  the  error  code  returned  is  other  than  one,  a  branch  to 
handle  the  specific  error  returned  is  accomplished.  Because  the  graphic 
operation  was  unsuccessful ,  the  error  code  parameter  to  be  returned  must  be  set 
to  a  meaningful  value,  in  this  case  either  a  -1  or  -2,  such  that  appropriate 
action  is  taken. 

CONCLUSION 

The  areas  of  greatest  effort  in  the  conversion  were  the  processing  methods 
of  current  cursor  position,  relative  moves  and  draws,  and  error  handling. 
Significant  bugs  were  discovered  during  testing  that  involved  the  current  cursor 
position.  All  calls  affecting  the  current  cursor  position  had  not  been 
identified  and  needed  to  be  debugged  with  appropriate  change  to  correct  the 
errors.  The  other  area  requiring  a  significant  amount  of  time  during  the 
testing  phase  was  determing  proper  operation  of  GKS  in  relationship  to  the  host 
operating  system.  Specific  requirements  were  not  properly  met  during 
installation  of  the  GKS  package  and  therefore,  resulted  in  some  errors. 

The  conversion  effort  alone,  was  successfully  completed  on  time  and  under 
budget,  but  it  was  determined  that  after  the  conversion  effort  was  completed, 
the  graphic  terminal  being  utilized  for  the  software  converted  is  not  currently 
supported  by  GK-2000.  This  was  not  a  problem,  though,  because  of  the 
standardization  introduced  by  GKS.  The  GIS  converted  to  GKS  is  part  of  a  much 
larger  system  which  has  an  interface  library  to  convert  the  GKS  calls  to  the 
targeted  terminal's  graphic  language. 

The  conversion  effort  has  resulted  in  greater  portability  and  has  given 
flexibility  for  USAETL  managers  to  more  effectively  plan  conversion  to  other 
host  systems  of  the  converted  GIS  while  making  the  only  requirement  for  graphic 
operations  to  be  that  a  GKS  compatible  graphic  package  installed  on  the  host 
system,  irrelevant  of  vendor. 
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ABSTRACT 

Digital  data  products  for  cartographic,  land-use,  and  tactical 
applications  are  becoming  increasingly  avaflable.     A   variety  of  products 
are  centrally  produced  for  internal,  inter-agency,  or  commercial 
distribution   by  such   agencies  as   USGS,   DMA,   USDA,   SCS,    NOAA,  and 
NASA.     Standard  data  formats  are  under  development  to  facflitate 
transfer  of  digital   map  information  on   magnetic  tape  among   potential 
users  in  the  GIS  community.     GIS  software  packages  are  designed  to 
create  internal  data  bases  directly  from  source  documents  and   vary  in 
their  capacity  to  integrate  digital   data  products. 

DBA   Systems,  Inc.,   under  contract  to  the  U.S.   Army  Engineer 
Topographic  Laboratories  (USAETL),  is  enhancing   AMS  to  allow  the  use 
of  SLF  terrain  analysis  data  from  the  Defense  Mapping  Agency  in  the 
Terrain   Analyst  Work   Station   (TAWS).   This  paper  discusses  the 
interface  of  SLF  data  to  AMS,  and  concerns  for  importing   multiple 
attribute  digital   data  to  a  GIS. 


INTRODUCTION 

The  SLF  Throughput  System   was  designed  as  an  enhancement  to 
the  Terrain   Analysis  Workstation/Geographic  Information   System 
(TAWS/GIS)  at  the  U.S.    Army   Engineer  Topographic   Laboratories 
(USAETL)  at  Fort  Belvoir,   Virginia.     The  TAWS/GIS  operates  a  version 
of  the  AMS/MOSS/MAPS  software  that  was  originally  developed   under 
government  contract  for  the  U.S  Fish  and   Wildlife  Service,  and  includes 
modifications  subsequently  developed   under  contract  to   USAETL. 

The  purpose  of  the  enhancement  is  to  provide  an  interface  to  the 
TAWS/GIS  to  accept  Standard  Linear  Format  (SLF)   digital  data  produced 
by  the  Defense  Mapping   Agency  (DMA).     The  SLF  Terrain   Analysis 
data  (SLF/TA)  is  a  digital   version   of  a  Terrain   Analysis  hardcopy 
product  at  a  1:50,000  scale.     The  data  is  in  the  form  of  thematic 
overlays  of  various  terrain  features  (eg.,  sofis,   vegetation,   slope, 
transportation)  for  a  particular  coverage. 

Terrain  information   produced  at  a  central  location   may  not  be 
current  or  contain  a  sufficient  level  of  detafi  required  for  tactical 
purposes.     Map  data  must  be  updated  according  to  the  latest  field 
information:     new  features  may  be  added,   boundaries  of  existing 
features   may  be  changed,  or  existing  features  may  be  described  at  a 
level  of  detail  not  present  in  the  source  data.   The  SLF  data  structure 
provides  the  flexibility  to  accommodate  various   products  at  different 
stages  in  their  production.     There  was  a  clear  need  to  provide  a 


mechanism   within  the  existing  system  of  the  TAWS/GIS  to  employ  this 
data. 

Specific  requirements  that  were  met  by  this   prototype  system  for 
throughput  of  the  SLF  data  in  the  TAWS/GIS  include: 

*  Transfer  of  the  SLF/TA  data  from   magnetic  tape  to  the  AMS 
subsystem  of  the  TAWS/GIS 

*  Export  of  locally  created  data  to  an  SLF  tape  for  transfer 
to  other  installations. 

*  Examination  of  alternatives  for  importing  and   using  a  digital 
data  base  with   multiple  attributes  for  map  features. 

The  SLF  throughput  software  was  developed  to  perform  on  a 
Hewlett-Packard  9030  computer,  operating   HP/UX    version  5.0,  at 
USAETL.     Initial  development  of  the  system  took   place  on  a  VAX 
11/750,  operating   DEC/ULTRIX   version   1.1. 


SLF  INPUT    DATA 

SLF  is  designed   by   DMA  to  be  a  portable,  flexible  and  efficient 
data  structure  for  exchange  of  digital  cartographic  data  via  magnetic 
tape  (DMA,  1985).     It  is  intended  to  become  a  standard   DMA   product. 
SLF/TA   data  used  in  the  TAWS   program  is  produced  on  the  Terrain 
Analysis  Production   System   (TAPS)  at  DMA  and  conforms  to  FIPS/ANSI 
standards  with  all  data  in  ASCII  characters.     This  data  is  a  digital 
version  of  the  DMA   TA   hardcopy  products  at  a  1:50,000  scale.     A   SLF 
data  file  will  normally  correspond  to  a  map  sheet  overlay  describing  a 
type  of  terrain  feature  (eg.  surface  materials,   vegetation,   slope  or 
drainage)'.     It  is  a  vector  data  structure  that  describes  the  point,  line 
or  aerial  feature  components  of  the  original   map   plus  the  attribute 
information  for  the  features.     The  format  of  the  SLF  data,  the  physical 
tape  blocks,  and  the  logical  record  fields  are  documented  in   DMA,  1986. 

SLF  maintains   DSI,  SEG  and   FEA  records.     The  DSI,  or  Data  Set 
Information,  contains  the  header  parameters,   history  and  specifications 
of  the  data  file.     The  SEG  record  contains  the  segment  and  coordinate 
data,  and  the  FEA  records  contain  the  attribute  description  of  the  map 
features.     Integral  to  SLF  is  the  "chain-node"  structure  which   requires 
that  a  segment  chain   be  stored  only  once  regardless  of  the  number  of 
features  which  it  bounds.     This  eliminates  double  storage  of  common 
boundaries.     SLF  stores  the  segments  and   provides  linkages  to  the 
features.   The  linkages  allows  the  feature  to  be  reconstructed  from  its 
component  segments.     Figure  1  illustrates  the  cross-referencing  between 
features  and   segments. 

A   variable  length  feature  header  record  is  provided  for  product 
specific  descriptive  information  at  the  feature  level.   The  overall  format 
is  defined   by  SLF  but  the  length  and  contents  of  the  feature 
description   are  defined  in   product  specific  appendices.     Figure  2  shows 
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Figure  1.  SLF  Logical  Record  Structure  of  the  SEG  and  FEA  Records.  Tlie  Segment  ID  and 
Feature  ID  are  Pointers  that  Link  the  Two  Record  Types. 
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Figure  2.  Expansion  of  a  FEA  Logical  Record  Showing  Some  of  the  Data  Fields  Present 
for  a  Surface  Drainage  and  Transportation  /  Navigable  Waterways  Feature. 
(Blocks  5  and  6  not  shown) 


an  example  of  a  Feature  Description  format  for  surface  drainage 
features. 

OVERVIEW    OF   THE   IMPORT   PROCESS 

A  requirement  of  the  SLF  throughput  specifies  the  capability  of 
making  modifications  to  the  source  SLF  data.     For  this  reason  the 
Analytical   Mapping  System   (AMS)   was  chosen  as  the  GIS  subsystem  to 
receive  the  SLF  data.     AMS  is  the  data  input  and  editing  component  of 
the  TAWS/GIS.     AMS   was  designed  to  create  a  database  locally  through 
manual  digitalizing  of  hard  copy  maps,  or  through  an  analytical 
stereo- pi  otter  or  light  table  mensuration  system  for  input  of  aerial   photo 
source  data.     The  Map   Overlay  Statistical  System   (MOSS),   which  is  the 
analysis  and  overlay  component  of  the  GIS,  does  have  an  existing 
format  to  receive  external  data  (via  the  ADDWAMS  system).     However, 
MOSS  does  not  allow  topological   modifications  to  the  existing  data  base 
as  does   AMS. 

The  enhancement  for  importing  digital  data  to  AMS  requires  a 
detailed  specification  of  internal   AMS   data  files  and  knowledge  of 
operational   procedures  so  that  the  system   will  recognize  the  "foreign" 
data. 

The  system   performs  the  following  functions: 

*  Displays  a  listing  of  the  data  files  on  the  SLF  tape 

*  Provides  a  formatted  dump  of  a  data  ffle  contents 

*  Creates  a  Summary   Report  of  the  contents  of  each  file 

*  Performs  a  partitioning  of  the  source  data  so  that  it 
can  be  imported  to  AMS  as  individual  subsets  of  the 
original  coverage. 

*  Creates  valid   AMS   data  files  from  the  SLF  topology  so 
that  data  can   be  displayed,   plotted,  registered  on  a 
base  map,   updated/edited,   verified,  and   databased. 

*  Creates  an  SLF  tape  from   AMS  data  files 

The  SLF  throughput  system  consists  of  five  separate  programs. 
These  programs  are  logically  connected   by  a  shell  script  and  involked 
by  selecting  the  desired   program  from  a  menu.     This  approach   makes 
the  system   user  friendly.     The  following  programs  are  defined  to 
provide  the  basic  requirements  of  the  interface: 

*  Provide  a  tape  summary  of  the  source  SLF  tape  (TAPESUM) 

*  Geographic   panelling  of  the  original  coverage  to  six  subset 
areas   (DIVSLF) 

*  Import  the  source  ffle  and   bufld  topological  AMS  data  ffles 
(IMPSLF) 


CONFIGURATION  FOR  SLF  THROUGHPUT  IN  THE  TAWS  GIS 
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Provide  a  formatted   dump  of  the  SLF  tape  contents 
(SLFDMP). 

Export  AMS  data  ffles  to  a  SLF  formatted  tape  (EXPSLF) 


The  Import  procedure  creates  a  set  of  AMS  data  files  from  the  SLF 
source  data.     The  new  data  ffles  reside  in  the  user's   work   area 
directory  and  specify  a  "geounit"   within   a  particular  AMS  Project/Theme 
which  the  user  has  set  up   prior  to  the  Import  SLF  job.     The  AMS 
software  is  not  modified  by  the  enhancement  except  to  add  another 
menu  option  to  the  start-up   menu.     The  main   programs  are  called   via  a 
secondary  menu.     After  the  import  is  completed,  the  user  can  register 
the  data  to  a  base  map  for  editing  purposes  or  proceed  directly  to  AMS 
verification  of  the  data  and   move  the  ffles  to  the  database  directory 
(AMS  functions).   Once  in  the  database  area,  the  data  can   be  brought 
back  for  update,  or  be  exported  to  the  MOSS  analytical   package  of  the 
TAWS/GIS. 

If  the  Subset  SLF  function  is  used,  a  set  of  six  disk  ffles, 
GE01-GE06,   will   be  created  in  the  user's  directory.     These  files 
contain  source  SLF  data  that  has  been   panelized   {geographically 
divided)  into  6  subareas.     Each   panel  can   be  imported  as  an   AMS 
geounit. 

AMS   FILE   STRUCTURE 

AMS   maintains  a  set  of  internal,  random  access  disk  files 
associated   with  an  input  job   (Figure  3).     The  data  structure  is  an 
"arc-node"  structure  that  explicitly  identifies  all  the  topographical 
elements  including  segments,   nodes,  edge  nodes,   polygons,  and 
coordinate  data.     Each  entity  type  is  contained  in  a  special  file.     A 
system  of  ffle  pointers  exist  to  cross-reference  all  the  connected 
elements  and  allows  the  software  to  maintain  the  integrity  of  the  data 
base  when  topological  elements  are  added,  deleted  and  modified. 

The  "arc-node"  data  structure  used  in   AMS  can   be  created  from  the 
simple  chain-node  structure  of  SLF  with  some  restructuring  and  creation 
of  new  information   unique  to  the  AMS  data  structures.     An  example  of 
this  restructuring  is  the  creation  of  the  AMS- "Normal   Node  Ffle". 
Nodes  are  important  elements  in  an  arc-node  data  structure.     They 
define  the  junction   where  two  or  more  segments  come  together.     In 
SLF,  nodes  are  not  explicitly  identified,   but  are  simply  the  first  and 
last  points  on  a  segment  "chain".     The  SLF  import  process  identifies 
these  points  as  nodes  and  assigns  linkages  required  by  AMS  to  identify 
the  segments  that  join  at  a  particular  node.     The  structure  of  the 
Normal   Node  Ffle,  including  pointers,  is  maintained  as  nodes  are  added. 

ATTRIBUTE    HANDLING 

SLF/TA  format  provides  a  hierarchical  arrangement  of  descriptive 
information  for  map  features   (Figure  2).     The  SLF  feature  description 
can   be  of  variable  size,  depending  on  the  feature  type  and  the  amount 
of  information  collected.     The  format  does  not  'map'  well  into  the  AMS 
structure  for  map  feature  attributes.     Attribute  tags  in   AMS  must  be 


AMS  DATA  FILES 


Record  in  the  SEGMENT  INDEX  FILE  (SIF) 

*  Pointers  to  record  in  the  SCD  file 

Left,  Center,  and  Right  feature  attributes 
Pointers  to  POL  for  Left,  Center,  and  Right  features 
Pointers  to  NNF  and  ENF  for  beginning  and  ending  node 
Minimum  bounding  rectangle  of  segment 


Subrecord  in  the  NORMAL  NODE  FILE  (NNF) 

Latitude  coordinate  of  node 
Longitude  coordinate  of  node 
Number  of  segments  attached  to  node 
*  List  of  record  numbers  in  SIF 


Record  in  the  SEGMENT  COORDINATE  DATA  FILE  (SCD) 

Number  of  coordinates  in  this  record 
Minimum  bounding  rectangle  of  this  record 
List  of  coordinate  points 


Subrecord  in  the  EDGE  NODE  FILE  (ENF) 

Delta  longitude  (for  an  edge  on  the  North  or  South  edge) 
Delta  latitude  (for  an  edge  on  the  East  or  West  edge) 
Record  number  in  SIF  for  segment  attached  to  the  edge  node 


Record  in  the  POLYGON  FILE  (POL) 

Feature  Number 

Minimum  bounding  rectangle  of  feature 
Area  of  feature  (if  polygon) 
Centroid  of  feature 
*  Type  of  feature  (point,  line  polygon) 

Pointers  to  SIF  for  segments  that  make  up  this  feature 

RESTART  FILE 

Contains  job  parameters  for  updating  and  displaying  geounit 


Figure  3.  List  of  Major  Data  Files  Required  by  AMS  and  Created  by  the  Import 

Process  (Except  POLYGON),  with  an  Abreviated  Listing  of  the  File  Contents. 
An  Asterisk  Indicates  the  Field  is  a  File  Pointer. 


I 
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contained   within  a  32  character  field.     For  practical   purposes,  only  18 
of  these  characters  are  displayed  to  the  user. 

The  interim  solution  adopted   here  is  to  save  the  SLF  feature 
descriptions  in  a  separate  disk  file  during  the  import  process.     A 
standard  feature  description  item,  the  Feature  Category,  or  FEACAT 
code,  is  extracted  for  every  feature  in  the  data  set  and  combine  with 
the  feature  ID   number  to  form  the  A  MS  attribute. 


CONSIDERATIONS   FOR   IMPORTING    MULTIPLE-ATTRIBUTE    DATA 

There  are  several  alternatives  for  using  the  full  feature 
descriptions  provided   by  SLF.     The  specific  approach   wfll   depend  on 
the  target  system  to  receive  the  imported  data,  the  method   used  for 
analysis  of  the  data,  and  the  generality  desired  in  the  import  software. 

Considerations  for  importing  data  to  AMS   must  take  into  account 
that  the  software  uses  a  single  attribute  tag  for  the  map  feature.     At 
USAETL,  the  TAWS   project  uses  a  coding  scheme  to  describe  levels  of 
information  for  each   map  feature.     The  coding  scheme  is  entered   when 
the  data  is  digitized.     Creation  of  terrain   products  in  the  MOSS 
subsystem  are  based  on   decoding  a  particular  coding  schema.     One 
alternative  for  importing  SLF  multiple  attributes   would  be  to  compress 
the  contents  of  the  Feature  Description   record  into  an  appropriate 
character  code.     This  approach  involves  a  rule-based   matching  of  data 
fields  from  the  feature  records  to  a  locally  used  coding  scheme.     Whfle 
this  approach   has  minimal  impact  on  existing  methods  for  data  analysis, 
it  is  limited  to  a  particular  system.     Also,  information  from  the  source 
data  may  be  lost  in  the  process  of  compressing  data  fields  to  a  coded 
representation . 

A   more  generalized  approach   would  allow  the  user  to  access  any 
and  all  attribute  fields  that  may  be  present  in  the  imported  data.     A 
digital  data  product,  such  as  SLF,  contains  varying  levels  of  detafl. 
The  user  may  want  to  preview  future  information  on  tape  to  determine 
what  may  be  present.     The  import  utility  would   have  the  capability  to 
down-load  the  feature  information  to  a  multiple-attribute  database.   The 
structure  of  the  feature  database  could  be  taflored  to  conform  to  a 
MOSS  multiple  attribute  ffle.     If  a  data  base  management  system   were 
integrated  to  the  GIS,  the  import  software  could  create  a  generic   "flat" 
file  that  could   be  accessed   by  the  DBMS.   These  alternatives  are 
currently  being  considered. 

Current  developments  in  digital  cartographic  exchange  formats 
emphasize  the  need  for  flexible  descriptions  of  map  attribute  data 
(Guptill,  1986).     In  order  for  these  data  products  to  be  fully  exploited 
by  the  intended  users,  it  is  important  that  the  GIS  software  be  able  to 
access  the  feature  description  component  of  the  data  product  with 
convenience  and  flexibility. 


CONCLUSIONS 

An  enhancement  to  AMS   was  developed  to  import  a  digital 
cartographic  data  base  from   magnetic  tape.     The  current  version 
translates  Standard  Linear  Format  (SLF)   data  to  internal   AMS  data 
files.     Alternatives  are  being  considered  for  importing  the 
multiple -attribute  component  of  the  SLF  data  product.     The  modular 
design  of  the  system   will  allow  a  modification  to  import  any  standard 
vector  data  product  with  an  arc-node  structure  (eg.USGS   Digital  Line 
Graph)  to  the  AMS  data  base.     The  principle  advantage  of  importing 
data  to  AMS  rather  than   MOSS  is  the  capability  in   AMS  to  make  changes 
to  the  source  data. 
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/iicac  >,u  iui_ai-iuii  oiiiu  3u  i  i  uypcrrj.  Final  analysis  consisted  of 
prioritizing  these  areas  and  producing  outputs  showing  location 
and  acreage. 

This  analysis  demonstrates  that  MOSS/MAPS  is  useful  in  providing 
results  that  aid  in  non— resource  decision  making.  Simply  stated, 
site  characteristics  determine  building  costs  and  accessibility 
in  developing  commercial  sites. 


INIRODUCIigN 

The  Bureau  of  Indian  Affairs  (BIA)  Albuquerque  Area  Office  ( AAO ) 
administers  E^  reservations/pueblos  in  their  jurisdiction.  The 
BIA  is  required  to  prepare  Natural  Resource  Management  Plans 
(NRMP's)  for  each  one  of  these.  In  198^,  steps  were  taken  to 
begin  preparing  a  NRMP  for  the  Nambe  Pueblo.  This  reservation 
was  chosen  to  begin  using  GIS  as  this  is  a  smaller  pueblo  and  yet 
possesses  a  wide  variety  of  natural  resources.  This  allowed  the 
opportunity  to  gain  experience  using  GIS  before  attempting  a 
larger  scale  project  elsewhere. 

The  Nambe  Tribal  Council  submitted  the  Tribal  Goals  and 
Objectives  ( G8«0 '  s )  to  the  BIA.  Contained  in  this  was  the  desire 
to  "Provide  for  Potential  Commercial  Development  (PCD)  Sites". 
The  Map  Overlay  Statistical  System  (MOSS)  and  Map  Analysis  and 
Processing  System  (MAPS)  was  used  to  determine  these  areas  along 
with  addressing  other  GScO  '  s  . 


DISCUSSION 


Procedures 

The  NRMP  team  consisted  of  13  individuals.  This  team  defined  the 
requirements  for  determining  PCD  Sites.  The  requirements  were: 
(1)  must  be  located  within  \/^  mile  of  existing  roads  to  minimize 
immediate  costs,  and  (2)  categorize  land  slopes  into  three 
groups.  Knowing  these  requirements  allowed  the  determination  of 
data  themes  needed  to  perform  analysis. 

There  were  El  data  themes  digitized  and  available  to  use  with 
MOSS.  The  themes  applicable  to  use  m  this  analysis  were:  (1) 
Reservation  Boundary,  (2)  Roads,  (3)  Soils  for  the  Nambe 
Irrigation  Project  (NIP),  and  (^)  Soils  for  the  remaining  Nambe 
Pueblo  (NIR).  There  were  not  any  Digital  Elevation  Models 
(OEM's)  available  from  the  United  States  Geological  Survey  ( USGS ) 
to  perform  slope  analysis.  This  necessitated  using  the  two  Soils 
themes  as  these  contained  the  only  available  slope  information. 
The  soil  attributes  categorized  soils  into   various  slope  ranges. 


Categorizing  Slope  Data 

The  soils  information  used  eight  different  slope  categories. 
Figure  1  shows  these  slope  categories.  As  this  illustrates, 
there  is  an  overlap  between  miost  of  the  categories.  The  NRMP 
team  chose  to  divide  these  categories  into  three  groups. 
Admittedly,  two  of  the  groups  overlap  with  one  another  (1-8%  and 
1-12'/.).  The  only  way  not  to  have  overlaps  is  if  there  were  only 
two  categories  used  (1-12*/.,  12-55*/.).  This  was  not  done  as  a  1- 
IS'/.  slope  group  is  too  broad. 


Analysis 

Each  data  theme  for  the  Nambe   Pueblo  is   organized  by   USGS  7.5' 
quadrangles.     The   Nambe   Pueblo   extends   onto   four   of  these 
quadrangles.     Due   to   this,   it   was   required   to   merge   the 
quadrangles   for    each   theme    to   allow   for   reservation-wide 
analysis.   This  merging  enabled  simpler  and  faster  analysis. 

After  merging  each  theme,   the  three   slope  groups   were  selected 

for   the   two   soil   themes   in   MOSS   and   plotted  to  a  graphics 

terminal.   At  this  point  it  was  noticed  that  their   were  overlaps 

between  the   soil  inventories   (Figure  2).    To  make  the  analysis 
more  accurate,  the  data  must  be   "cleaned-up"  before   merging  the 

slope  groups   of  the   two  soils   themes.     To  make   this  easy  and 

fast,  it  was  determined  to  perform  this  "clean-up"  using  MAPS. 
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Since  data  must  be  rasterized  to  use  MAPS,  the  cell  size  must  be 
determined.  At  this  point,  the  distance  to  paved  roads 
requirement  for  PCD  sites  was  used.  Sites  must  be  within  1/^ 
mile  (1,320  feet)  of  paved  roads.  Next,  cell  height  and  width 
was  calculated  for  various  cell  sizes.  It  was  observed  that  .^ 
acre  cells  using  a  ratio  of  1,  ars  1 3£  x  132  feet.  Using  this 
cell  size  means  10  cells  will  equal  a  1/^  mile  exactly.  Each 
theme  was  then  rasterized  to  .^  acre  cells  using  the  RASTERIZE 
command  in  MAPS. 

The  soil  survey  for  the  NIP  was  determined  to  be  a  more  intense 
survey  than  the  NIR  soil  survey  and,  therefore,  a  more  accurate 
data  base.  Each  slope  group  in  the  NIP  soils  theme  was  used  to 
"cookie  cutter"  the  NIR  soils  removing  overlaps  from  the  NIR 
soils  theme.  This  was  accomplished  using  the  BOOLEAN  command  in 
MAPS.  After  this  was  finished,  the  two  soil  themes  were  merged 
together  making  one  slope  theme  consisting  of  three  groups. 

Next,  the  paved  roads  theme  must  be  combined  with  the  slopes 
theme  to  determine  those  slopes  within  1/^  mile  of  the  roads. 
This  was  accomplished  using  the  PROXIMITY  command  in  MAPS.  Figure 
3  shows  the  results  of  this  analysis.  From  the  new  map  created, 
an  acreage  summary  for  each  slope  group  that  meets  the  PCD  site 
requirements  is  listed. 

1  -  8  y.  slopes  862  acres 

1  -12  '/.  slopes  130  acres 

12-55  •/.  slopes  1,503  acres 

TOTAL  2,^95  acres 


QQNQUyilQN 

This  analysis  provides  a  good  example  of  how  GIS  can  be  used  to 
resolve  planning  problems.  GIS  does  not  necessarily  need  to 
analyze  natural  resource  conflicts.  The  information  obtained  can 
help  the  Nambe  tribe  determine  PCD  sites.  Depending  on  the  type 
of  commercial  development  the  tribe  desires,  the  appropriate 
desired  slope  for  the  development  can  now  be  located  and 
identified.  The  1-12  '/.  slope  category  will  necessitate  an  on- 
ground  inspection  as  it  too  has  areas  that  are  in  the  1-8  V.  slope 
range.  For  a  more  dependable  slope  breakdown,  the  1-8  */.  and  1-12'/. 
slopes  can  be  combined  creating  a  1-12  '/.  slope  group  that  has  no 
overlaps.  This  group  and  the  12-55  '/.  slope  group  creates  two 
distinct  slope  classes. 

This  analysis  will  probably  be  repeated  during  FY88  when  DEM ' s 
are  created  and  purchased  for  the  Nambe  Pueblo  area.  This  will 
provide  for  more  reliable  slope  information  and  also  the  ability 
to  choose  an  exact  slope  range. 
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ABSTRACT 


This  paper  presents  a  specific  routine  of  MOSS/MAPS  cominands 
used  in  displaying  the  natural  resources  on  30,000  acres  of 
forested  land  on  the  Fort  Apache  Indian  Reservation,  and  in 
analyzing  the  use  of  that  land  by  the  cattle,  timber, 
recreation,  and  tourism  industries.  The  materials  generated 
by  these  procedures  were  used  in  presenting  a  proposed  sale 
of  timber  on  that  land  to  the  Tribal  governing  body.  It  was 
generally  agreed  that  this  first  comprehensive  integration 
of  a  computerized  Geographic  Information  System  (GIS)  into 
forest  management  procedures  represents  a  significant  step 
forward  in  the  Agency's  management  of  timber,  and  holds 
promise  of  affecting  a  major  change  in  Tribal-Bureau  efforts 
in  jointly  managing  tribal  natural  resources. 


INTRODUCTION 

A  computerized  Geographic  Information  System  (GIS)  is  being 
used  by  the  Bureau  Of  Indian  Affairs  to  prepare  maps  and 
accomplish  analysis  in  support  of  forestry  operations  on  the 
White  Mt.  Apache  Reservation  in  Arizona. 

The  hardware  includes  a  Data  General  20  with  142  MB  of  disk 
storage,  a  Hewlett  Packard  7585  plotter,  a  CalComp  9100 
digitizer,  and  three  Visual  500  graphics  terminals.  The 
software  used  in  preparing  data  for  this  paper  was  version 
8509  of  the  BLM  MOSS. 


justification  for  use  of  a  computerized  GIS  includes  a 
tribal  water  rights  suit  against  the  State  and  Federal 
governments,  and  a  billion  dollar  suit  against  the  Federal 
government  for  mismanagement  of  Tribal  natural  resources. 

This  paper  discusses  some  of  the  MOSS/MAPS  commands  used  in 
analyzing  the  interrelationships  of  the  pertinent  natural 
resources  in  preparing  a  timber  sale  for  approval  by  the 
tribal  governing  body. 


GOALS  FOR  THIS  PROJECT 

Display  areas  proposed  for  n_o  logging  or  minimal  logging; 
Streams 
Lakes 

Campgrounds 
Cienegas 

Eagle/Osprey  Nests 
Elk  Hiding  Cover 

Display  areas  proposed  for  seasonal  logging; 
Certain  Soils 
Elk  Calving  Areas 
Elk  Migration  Routes 
Hunting  Areas 

Calculate  impact  of  above  on  timber  industry. 

Do  various  Sorts  for  Forest  Management  Planning. 


STRATEGY 

The  sequence  of  MOSS/MAPS  commands  we  used  was  dictated  by; 

Inadequacies  of  some  commands; 

BUFFER  -  So  use  MAPS 

OVERLAY  -     use  MAPS 

INTERSECT  -     use  MOSS 

HEWLETT  -     use  MOSS 

Use  of  a  non-quad  format; 

use  MAPS 

Complex  vegetative  cover  map; 

use  MAPS 

Inevitable  request  to  sort/select  from  final  map; 

use  MOSS 

Those  conflicting  requirements  and  needs  result  in 
procedures  that  are  time  consuming,  interim  products  that 
are  not  entirely  satisfactory,  and  the  need  for  a  higher 
operator  skill  level  than  would  otherwise  be  necessary. 


PROCEDURES 


The  first  step  in  the  routine  was  to  reformat  all  of  our 
themes  from  quad  format  to  timber  management  unit  format. 
(Commands  are  capitalized;  MOSS  commands  are  underlined, 
MAPS  not) ; 

SELECT,  using  the  ^subject'  option,  the  desired  timber 
management  unit  from  the  7  1/2  minute  quad  timber  management 
unit  theme  map.  Do  the  same  for  the  other  four  quads 
containing  that  management  unit. 

MERGE  those  five  new  maps,  creating  the  timber  mgm't.  unit 
theme.  The  above  two  operations  take  5-10  minutes.  (Use 
DISSOLVE  if  you  have  the  Jan.  87  BLM  version  of  MOSS.) 

SELECT,  using  the  ^All'  option,  the  five  vegetative  cover 
maps  which  encompass  the  timber  mgm't.  unit.  5-10  minutes. 

MERGE  those  five  vegetative  cover  maps.  1  hour  or  so. 
(Several  hours  with  DISSOLVE. )  Repeat  the  above  two  steps 
for  Roads,  Streams,  Lakes,  Soils,  Public  Land  Surveys, 
Springs ,  etc . . 

WINDOW  the  mgm't.  unit  map. 


I 

I 

OVERLAY  the  mgm't.  unit  map  on  the  five  quad  vegetative  ■ 

cover  map,  using  the  Yes  option,  0  characters  from  the  first 

map,  and  15  from  the  second  (15  characters  in  the  vegetative 

cover  map's  subjects),  using  the  intersection  option.  Go 

home  for  the  weekend.  Repeat  the  above  two  operations  for 

each  of  the  polygonal  themes, 

WINDOW  the  mgm't.  unit  theme,. 

LPOVER  the  mgm't.  unit  map  on  the  five  quad  road  map. 
Specify  0  characters  from  the  first  map  and  the  appropriate 
number  for  the  second.  Run  on  a  three  day  weekend.  Repeat 
the  above  two  steps  for  each  line  theme. 

The  overlay  operations  will  create  many  tiny  polygons, 
especially  if  Merge  rather  than  Dissolve  was  used.  It  is 
desirable  to  remove  those  polygons; 

WINDOW  the  mgm't.  unit  map. 

SIZE  the  vegetative  cover  map,  for  example,  using  1  acre  as 
the  minimum  size  and,  as  maximum  size,  a  number  larger  than 
the  area  of  the  largest  polygon. 

SAVE  the  map  resulting  from  the  size  operation;  that  is  the 
final  vegetative  cover  map,  we  hope. 


The  next  step  is  to  prepare  data  for  those  who  do  Timber 
Management  Planning.  They  want  the  vegetative  cover  map 
broken  down  into  about  30  subcategories,  such  as: 

Pure  Pine  site  quality  3 
Pure  Pine  site  quality  4 
Pure  Pine  site  quality  5 
Pure  Pine  site  quality  6 
Pure  Spruce  site  quality  3 
etc . 

We  do  that  in  batch  in  MOSS  using  the  SELECT  command  with 
the  FROM  option; 

SED  SELEMAPS 

MAVALLTTY 

STOP 

SED  SELEFROM 

CLIFF 

OPEN  APACHE 

SELECT  FROM 

SELEMAPS 

PUREP3 

SELECT  FROM 


I 
I 
I 
I 
I 
I 
I 
I 
I 
I 
I 
I 
I 
I 
I 
I 
I 
I 
I 


SELEMAPS 

PUREP4 

etc. 

ACTIVE 

BYE 

QBATCH/I 

MOSS. BATCH  APACHE 

SELEFROM 

) 

We  then  MERGE  those  30-40  subcategories  into  the  8  groups 
that  the  rest  of  the  project  is  interested  in. 

All  of  the  above  data  is  considered  tentative  at  this  point, 
because  experience  has  shown  that  the  Overlay  command 
sometimes  produces  strange  results.   So  we  make  a  graphic  of 
those  8  groups.   If  there  are  no  overlaps  or  gaps  on  that 
graphic,  then  we  feel  secure  in  proceeding  onward. 


I  will  point  out  a  few  tricks  we  have  learned  in  using  the 
Hewlett  command  in  MOSS. 

The  command  accepts  and  uses  correctly  pen  numbers  1-8. 

It  always  uses  pen  #1  in  the  attribute  option. 

If  the  units  of  measurement  are  Feet,  then  the 
default  increment  length  is  correct,  and  the  3  Bar 
scale  divisions  are  2000,  2000,  and  4000. 

The  dashed  shading  doesn't  work. 

The  legend  sometimes  plots  over  the  annotation 
space,  for  some  critical  size  of  map.  Usually 
correctable  by  entering  the  legend  on  the  lower  part  of 
the  screen  when  using  the  Utility  8  command.  I 
haven't  researched  this  sufficiently  to  predict  the 
occurrence  of  the  overprinting. 

The  greatest  waste  of  time  was  in  learning  what 
entries  to  use  for  "Distance  between  Pinch  Wheels" 
when  using  the  Rotate  feature  of  the  HP7585  and  when  a 
map  would  just  fit  34"  x  44"  paper  if  it  were  properly 
centered.  When  using  the  Rotate  button  the  distance 
between  pinch  wheel  entry  is  nominally  44", rather  than 
the  normal  34".  It  happened  that  our  very  first  project 
map  would  barely  fit  the  34"  dimension  (with  the  Expand 
pin  on  the  back  of  the  plotter  ON)  if  it  were  properly 
centered.  After  much  experimentation  we  found  that 
entering  42"  for  the  distance  between  pinch  wheels 


'fooled'  the  software  and/or  machine  into  centering  the 
map,  with  about  1/4"  to  spare.  Unfortunately,  several 
of  our  timber  management  unit  maps  fit  34"  x  44"  paper 
only  by  manipulating  the  pinch  wheel  entry,  which 
involves  considerable  time  in  experimentation. 


*  * 


The  most  devious  of  our  procedures  involved  the  buffering  of 
streams  and  roads,  and  the  subsequent  determination  of  the 
acreage  of  commercial  timber  in  those  buffers; 

SELECT  using  the  Subject  option,  the  Perennial  streams  from 
the  stream  map.  In  our  case  the  subject  string  was 
PSIPERSTR. 

WINDOW  the  timber  management  unit  map. 

BUFFER  the  perennial  stream  map. 

.3079  <>   (1/2  the  total  400"  buffer,  in  miles.) 

No  <>    to  resolve  overlaps  since  it  doesn't  work,  which  is 
why  the  rest  of  the  procedure  is  in  MAPS. 

WINDOW  the  timber  management  unit  map,  in  MAPS. 

RASTERIZE    the  buffer  map,  TYPE  7,  HEIGHT  30  WIDTH  30. 

RASTERIZE    the  commercial  timber  map,  as  above. 

WINDOW    the  timber  management  unit  map 

INTERSECT  the  rasterized  buffer  map  with  the  rasterized 
commercial  timber  map.  The  resulting  map  is  a  map  of  the 
commercial  timber  within  the  buffer.  The  acreage  of  that 
timber  is  quickly  gotten  with  the  AREA  command,  using  the 
Totaling  option. 

It  is  not  practical  to  sort  the  results  of  the  Intersect 
command  into  subcategories,  such  as  timber  species.  Since  we 
usually  do  need  output  by  species,  it  is  necessary  to  do  the 
sorting  in  MOSS,  prior  to  entry  into  MAPS,  as  shown  below. 

************* 


To  determine  the  acreage  of  commercial  timber,  by  species, 
on  soils  that  should  be  logged  only  when  dry  or  frozen; 

SELECT,  using  the  ^subject^  option,  the  pertinent  soils  from 
the  soils  map  previously  made,  entering 


■ 


03E!22E!35E!41E!55B  as  the  search  string. 

WINDOW  the  timber  ingm't.  unit  map,  in  MAPS 

RASTERIZE  the  new  soils  map  and  maps  previously  made  in  MOSS 
of  Pure  Pine,  Pure  Spruce,  Pure  Aspen,  and  Mixed  Conifers, 
using  the  same  cell  format  as  before;  Type  7  HEIGHT  30  WIDTH 
30. 

WINDOW  the  timber  mgm't.  unit  map 

INTERSECT  each  of  the  species  maps  with  the  soils  map, 
separately,  and  get  acreages  of  all.  Very  time  consuming 
process.  Keep  reminding  yourself  that  this  operation  is 
practically  impossible  to  do  manually. 


One  of  the  final  steps  is  to  produce  a  map  showing  the 
commercial  timber,  by  species,  that  is  not  involved  in  any 
of  the  various  restrictions.  The  need  for  this  type  of 
analysis  is  the  main  reason  for  the  use  of  MAPS. 

WINDOW  the  timber  mgm't  unit  map 

COVER  the  commericial  timber  map  of  Pure  Pine  with  each  map 
containing  restrictions.  The  command  looks  like; 

COVER  RMAVPP  WITH  RMAVSLSDF  WITH  RMAVLAKBUF  WITH 
RMAVSTRBUF  WITH  RMAVGRBUF  WITH  RMAVELKCAF  WITH  , 
,  RMAVCABLE  WITH  RMAVCAMBUF  WITH  RMAV 

Repeat  the  Cover  command  for  each  species  of  timber. 


CONCLUSION 


The  CIS  has  proven  to  be  an  effective  tool  for  portraying 
and  analyzing  natural  resource  information  on  the  Fort 
Apache  Indian  Reservation. 

As  MOSS  is  enhanced  to  provide  faster  processing  times,  and 
the  defective  commands  are  improved,  we  anticipate  an 
integration  of  GIS  into  all  aspects  of  natural  resource 
management,  with  a  substantial  increase  in  our  ability  to 
manage  those  resources  to  the  satisfaction  of  the  owner. 


MISSION  NEARLY  IMPOSSIBLE 


Building  Multiple  Attribute  Tables  on  the  Data  General  DG-20 


Robert  W.  Klaver,  CIS  Coordinator,  U.S.  Department  of  the  Interior,  Bureau  of 
Indian  Affairs,  Portland  Area  Office,  P.O.  Box  3785,  Portland,  OR   97208 

This  paper  describes  how  multiple  attribute  may  be  entered  on  a  personal 
computer  (PC)  using  a  data  base  management  system  (DBMS)  and  added  to  MOSS. 

Resource  managers  think  in  terms  of  multiple  attribute.  For  example,  a  soil 
scientist  is  not  interested  in  just  the  soil  type  but  on  its  suitability  for 
septic  tanks,  erosion  potential,  etc.  For  a  geographic  information  system  to 
be  useful,  it  must  be  able  to  describe  spatial  data  by  a  multiple  of 
attributes . 

MOSS  Commands  to  add  multiple  attributes  to  spatial  data  are  ATTRIBUTE  and 
ATTDES.  ATTRIBUTE  is  the  main  multiple  attribute  support  utility.  This 
program  allows  entry  of  attributes  either  from  the  keyboard  or  a  file. 
Keyboard  entry  of  attributes  is  straight  forward  but  is  impractical  when  there 
are  many  features  and/or  attributes. 

The  more  useful  way  of  adding  attributes  is  from  a  data  file.  ATTDES  is  the 
support  utility  for  describing  the  structure  of  the  data  files.  ATTRIBUTE  and 
ATTDES  require  multiple  attributes  to  be  in  an  ASCII  file  with  each  variable 
in  specific  columns. 
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The  Data  General  DG-20  does  not  have  a  DBMS  available  to  easily  create  these 
data  files.  Attributes  can  be  entered  by  typing  each  variable  into  a  file, 
being  careful  to  keep  columns  properly  aligned;  a  tedious  and  confusing 
process.  Data  entry  programs  can  be  written  to  prompt  for  each  variable  and 
write  it  in  the  proper  format  to  a  file.  GIS  users  generally  are  not 
programers;  so  this  is  not  usually  a  viable  alternative. 

Functions  in  DBMS  are  data  definition,  entry,  editing,  listing,  and 
import/export.  These  features  allow  for  easy  creation  of  multiple 
attributes.  Programming  ability  is  not  required  but  a  knowledge  of  the  data. 
The  field  sheet  provides  the  details  on  the  data  format. 

The  data  base  is  created  with  fields  named  and  formated  as  described  on  the 
field  sheet.  For  example,  if  habitat  type  is  recorded  as  a  3-digit  number,  a 
field  named  "habitat  type",  width  3,  data  type  integer  occurs  in  the  DBMS. 
Data  from  field  sheets  are  added  to  the  data  base.  Most  DBMS  allow  the  use  of 
a  data-entry  form  that  looks  identical  to  the  field  sheet.  This  facilitates 
the  entry  of  data  and  minimize  errors. 

MOSS  requires  each  feature  to  have  its  own  list  of  multiple  attributes.  If  a 
subject  occurs  as  several  features,  that  record  needs  to  duplicated  for  each. 
Additionally,  the  multiple  attribute  table  needs  to  be  in  the  same  order  as 
the  subjects  on  the  map.  This  can  be  done  by  adding  an  additional  field  in 
the  DBMS  called  "subject  order".  The  value  of  this  field  is  the  item  number 
of  the  feature.  The  DBMS  should  be  sorted  by  "subject  order"  before  it  is 
exported. 
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To  use  these  data  in  MOSS,  the  data  must  be  exported  from  the  DBMS  into  an 
ASCII  file.  Most  DBMS  allow  for  the  selection  and  reordering  of  attributes 
when  data  are  exported.  This  new  file  should  be  exported  in  fixed  record 
format.   All  attributes  for  a  spatial  feature  comprise  one  line  of  data. 

After  creating  the  ASCII  file,  it  must  be  transferred  from  the  PC  to  the  Data 
General.  Several  communication  packages  are  available  and  I  recommend 
selecting  a  program  that  preforms  error  checking.  A  useful  file  transfer 
program  is  Kermit;  a  public  domain  program  distributed  by  Columbia 
University.   Kermit  is  available  for  many  micro  and  mainframe  computers. 

The  multiple  attributes  are  added  to  the  MOSS  map  by  first  defining  the  format 
with  ATTDES  and  adding  them  with  ATTRIBUTE.  A  copy  of  the  description  of  the 
DBMS'S  fields,  their  data  type  and  length  provides  the  response  to  the  prompts 
in  ATTDES. 

DISCUSSION 

This  procedure  was  developed  because  I  could  not  find  a  DBMS  for  the  Data 
General  DG-20  computer.  There  are  other  reasons  why  this  is  a  useful 
procedure,  regardless  the  computer  system  running  MOSS. 


Data  may  already  be  available  on  PCs.  For  example,  SCS  developed  a  PC  version 
of  their  Soils-5  database.  DBMS  programs  are  useful  tools  to  reformat, 
select,  and  sort  data  downloaded  from  other  computers.  If  data  are  in  a 
tabular  format,  they  can  be  directly  added  to  a  DBMS. 
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Once  in  the  DBMS,  the  data  may  be  manipulated  as  required  by  MOSS.  For 
example,  Canada  Goose  observations  were  on  the  University  of  Montana 
computer.  These  data  were  transferred  with  Kermit  to  a  PC,  added  to  a  DBMS, 
exported  as  point  data  for  XYSUBJECT  and  as  multiple  attributes  for  ATTDES  and 
ATTRIBUTE. 

Building  multiple  attributes  can  save  money  at  data  entry  and  make  feature 
selection  easier  for  the  MOSS  user.  For  example,  digitizing  timber  types  for 
the  Colville  Indian  Reservation  was  estimated  to  cost  $40,000  using  a 
complicated  subject  label.  The  estimate  using  a  multiple  attribute  file 
already  available  on  a  PC  was  $25,000.  Using  multiple  attributes  not  only 
saved  $15,000  but  made  the  selection  of  features  easier.  Features  can  now  be 
selected  simply  by  specifing  variable  name  and  value. 

Building  multiple  attribute  tables  on  a  PC  removes  this  processing  and  storage 
space  from  the  CIS  computer.  On  small  systems  and  limited  disk  space,  this 
advantage  may  overcome  the  nuisance  of  having  the  data  on  2  computers. 

Finally,  having  the  multiple  attributes  in  DBMS  and  MOSS  provides  added 
flexibility  for  reporting  and  analysis.  DBMS  are  excellent  for  report 
preparation.  Just  as  data  may  be  exported  and  added  to  MOSS,  data  may  be 
exported  and  used  with  a  variety  of  application  programs  such  as  statistical 
packages  and  home  range  programs.  By  having  the  multiple  attribute  in  the 
DBMS,  the  data  may  be  analyzed  by  the  most  appropriate  program. 

DBMS  have  been  a  useful  tool  to  create  multiple  attribute  files.  A  knowledge 
of  the  field  data  is  required,  not  the  ability  to  write  computer  programs. 
This  process  does  not  depend  on  a  specific  program  but  can  be  done  by  any  DBMS 
that  exports  files  in  tabular  format. 


PRODUCING  LAND  COVER  MAPS  SUITABLE  FOR  MOSS  FROM  MANUAL 
INTERPRETATION  OF  LANDS AT  THEMATIC  MAPPER  IMA3ERY 


Chris  English,  USBIALand  Operations  Office,  San  Carlos  Agency, 
San  Carlos,  Arizona.   Randy  McKinley,  Tracey  Feagan,  TGS  Technology 
Inc.,  ELM  Denver  Technical  Center,  Lakewood,  Colorado.   Robert  Haas, 
TGS  Technology  Inc.  ,  EROS  Data  Center,  Sioux  Falls,  South  Dakota. 

William  J.  Bonner,  Jr.,  Bureau  of  Indian  Affairs,  Lakewood,  Colorado. 
ABSTRACT 

The  Bureau  of  Indian  Affairs  investigated  manual  mapping  of  vegetative  land 
cover  and  initial  soil  mapping  units  as  a  technique  to  save  time  and  money  in 
the  initial  phases  of  a  soil  and  range  survey.  Landsat  V  Thematic  Mapper 
false  color  composites  at  1:100,000  scale  overlaid  with  mylar  were 
interpretted  by  hand  after  a  three  level  vegetation  classification  framework 
was  established.  This  map  was  captured  as  a  MOSS  data  theme.  Estimated  time 
and  dollar  savings  are  56  to  75  and  33  to  70  percent  respectively. 
A3ditionally ,  the  project  produced  a  data  theme  with  many  other  uses  and  a 
hard  copy  record  of  large  scale  land  use  information  for  the  San  Carlos  Indian 
Reservation  on  two  June,  1985  dates. 

INTRODUCTION 

In  1970  Sapp  et.al.  strongly  supported  the  use  of  remotely  sensed  products  for 
analysis  and  evaluation  of  Interior  Department  resources.  Haas  (1986), 
Degloria  and  Colwell  (1986)  reinforced  Sapp's  affirmation,  using  data  from  the 
most  recent  U.S.  Earth  Resource  Observing  Satellites,  the  Landsat  Thematic 
Mapper  (TM)  to  map  and  monitor  various  land  uses. 

The  Bureau  of  Indian  ;tfairs  (BIA)  Phoenix  Area  (Arizona,  Nevada,  Utah  and 
Southern  California)  is  allocated  three  (3)  cents  per  acre  for  range 
management  by  Congress.  Comparatively,  in  the  same  region,  the  Forest  Service 
is  allocated  42  cents  per  acre,  the  Bureau  of  Land  management  15  cents  per 
acre,  the  National  Park  service  57  cents  per  acre.  Each  agency  is  responsible 
for  conducting  resource  inventories,  establishing  carrying  capacity  for 
livestock  and  wildlife  and  monitoring  forage  utilization.  Accomplishing  these 
three  functions  within  prescribed  guidelines  requires  efficiency.  The  San 
Carlos  Agency,  Branch  of  Land  Operations  has  investigated  satellite  imagery  as 
a  tool  to  develop  an  initial  land  cover  map  for  a  230,000  acre  area  scheduled 
for  a  soil  and  range  inventory. 

In  standard  soil  and  vegetation  surveys  using  nine  by  nine  inch  aerial 
photography,  up  to  one-third  of  the  survey  time  and  expense  is  used  to 
establish  initial  mapping  unit  polygons.  Experience  from  other  work  suggested 
that  TM  imagery  would  provide  a  suitable  base  map  to  substitute  for 
traditional  techniques  in  a  low  intensity  (Order  III  or  IV)  soil  survey  and 
mapping  of  plant  community  types. 


TECHNIQUE 

Two  Landsat  V  TM  1:100,000  scale  images  were  obtained  to  compare  the 
effectiveness  of  various  band  combinations  for  mapping  vegetation  and  soils. 
These  false  color  images  used  bands  5,4  and  3,  measuring  reflectance  in  the 
mid  infrared,  near  infared,  and  red  spectral  regions  respectively;  and  bands 
4,3  and  2,  measuring  reflectance  in  the  near  infrared,  red  and  green  regions 
respectively.  Previous  efforts  at  mapping  soils  and  most  other  resource 
mapping  applications,  have  focused  on  computer  processing  Landsat  digital  data 
(DeGloria  et  al.  1986,  Haas  1986,  Roudabush  et.  al.  1985).  In  this  effort 
work  was  designed  to  develop  a  technique  permitting  a  field  technician  to  use 
the  false  color  images  for  manual  interpretation  of  resource  types. 

A  modified  Mderson  three  level  land  use/land  cover  classification  framework 
was  developed  as  discussed  by  Haas  (1986)  with  Level  I  identifying  the  land 
use/land  cover  classes  at  a  general  level  from  which  levels  II  and  III  could 
be  developed.  Level  II,  the  natural  terrestrial  vegetation  physiognomic 
classification,  was  determined  by  aerial  coverage  and  height  of  the  vegetative 
component.  Level  III,  the  plant  community  type  was  identified  by  the  names  of 
the  primary  or  the  primary  and  secondarily  dominant  plants  of  an  identified 
vegetative  community  (Table  1)  .  Ttie  framework  is  used  to  identify  plant 
communities  and  name  them  as  field  data  is  collected. 

Base  mapping  is  essential  for  scaling  TM  products  and  locating  political 
boundaries  on  polyester  drafting  film  (mylar)  worksheets.  The  USGS  1:100,000 
scale  land  ownership  series  was  selected  in  this  instance  because  coverage  is 
available  for  most  of  the  nation,  it  is  an  accurate  stable  base  for  data 
capture,  and  the  use  of  TM  imagery  at  1:100,000  scale  is  optimal.  A  sheet  of 
mylar  was  first  laid  over  the  USGS  map.  Latitude  and  longitude  grid  tic  marks 
were  transferred  for  later  use  in  digital  data  capture.  Significant  cultural 
features;  highways,  stock  watering  ponds,  a  dam  and  reservoir  were  used  to 
identify  reference  areas.  These  and  the  reservation  boundaries  were 
transferred  to  the  mylar  land  use/land  cover  base  map. 

The  mylar  base  map  was  then  overlaid  on  the  TM  image  and  the  cultural  features 
registered.  More  bodies  of  water,  riparian  zones  and  very  large  readily 
apparent  landscape  units  were  mapped  first.  The  mapping  following  was  more 
detailed  using  a  290  hectare  (640  acre)  minimum  mapping  unit  area. 

Upon  completion  of  mapping,  a  film  positive  of  the  mylar  was  made  to  be  used 
for  the  digital  capture  stage.  This  product  was  later  used  as  an  overlay  for 
collecting  field  ground-truthing.  Initial  digitizing  was  done  on  a  Hewlett 
Packard  using  IDIMS/GES  to  produce  field  maps  plotted  at  1:100,000  to  assist 
in  ground-truthing.  Ground  truthing  edits  were  made  on  the  plotted  hard 
copy.  Plots  were  also  made  at  1:62,500  and  1:24,000  scales  to  check  mapping 
accuracy  with  contour  lines  and  perform  detailed  ground-truth  edits.  All 
final  plotting  of  the  mapping  data  has  been  made  on  AMS  and  the  final  products 
are  satisfactory. 


TABLE  1:   An  example  of  a  modified  Anderson  three  level  land  use/land  cover 
classification  framework 


BIA  VEGETATION  CLASSIFICATION  FRAMEWORK 

U/10/86 


LEVEL  I  LEVEL  II  LEVEL  III 

1.    URBAN 


2.  AGRICULTURE  2A  IRRIGATED  AC 

2B  dryland  AC 

3.  NATURAL  3A  FOREST 
TERRESTRIAL  VEC. 


3»   WOODLAND 


WETLASD 


I 
I 


3A1 

PONDEROSA  PINE 

3a2 

DOUGLAS  FIR 

3A3 

PINVON 

3A'. 

MIXED  FOREST 

3B1 

PINE/JUNIPER 

3B2 

JUNIPER/PINE 

333 

HESQUITE 

3B4 

OAK 

3B5 

PINYON 

3C   WOODLAND/SHRUB  3C1  JUNIPER/SCRUB  OAK 

3C2  JUNIPER/HESQUITE 

3C3  PINYON/SCRUB  OAK 

3C4  PINYON/MESQUITE 

305  PINYON/MIXED  SHRUB 

3C6  JUNIPER/MIXED  SHRUB 

3D  SHRUB/WOODLAND  3D1  SCRUB  OAK/JUNIPER 

3D2  SCRUB  OAK/PINYON 

3D3  MANZANITA/JUNIPEE 

3D*  MANZANITA/PINYON 

3E   SAVANNAH  3E1  JUNIPER/MIXED  CRASS 

3F   SHRUSLAND  3F1  MIXED  CHAPPARAL 

3F2  CEONOTilUS 

3F3  SCRUB  OAK 

3F4  ACACIA 

3F5  KAflZAMTA 

3Ft  JOJOBA 

3F?  ."/.  :.0V-.  RDL 

JFo  c;-.-;soTf: 

..  5  c:  sosot:-:,  acat,: a 

^;.-.i  y.''.;    MAIiCCAt^V  't:   -:.£nU:iH 

■V  .  ■.  ;  ALOV^.  HLE/jrj;;PA 

JFU  :ALOV:.ROt,'Cl;OLI  A 

J-        SHRUB /Hi;  Kb  2C1  HESM  1 1  E /.".  I  ::i: '■    C  :.  A  j  S 

2^:  J'!. :  !'EF, /.'■.::a.u  C-',-.:s 

2C3  sj:ji::  oak/mixe:.  •;ka:;s 

3ci  c:o;;0Tiius/M:>;E;j  „:j,ass 

3C5  ACACIA/M'XED  c,^.^ss 

3C6  Kiy.ZD    SI;F,UB/M  :  XED  CRASS 

3U        LOW     51IRUB  3H1  S  S'A  KF.WE  i;  D 

Jil2  BUCKWHEAT 

3H3  BUCC.WiiF.  AT/ PALO  VERDE 

31   LOW  SHRUB/HEKSACEOUS    311  f NAK; WEF D / B LACK  CRAMMA 


3J   HERBACEOUS 


LOW  CJVZK 


3J1 

GRASSLAND  -  WARM  SEASON 

3J2 

crassla:;')  -  r-c.  l  r,i:ASO.s 

3J3 

a:.?,'UAL  GRASS 

3J4 

-TRASS/HIXtD  31:R':3 

3K1 

:  R  F  0  J  i  ~  E 

j  y.  2 

■'•■''  '' '  ' 

4A1 

SALT  CLCAK 

iA2 

MESQUITE 

i.A3 

CREOSOTE/MESQUITE. WILLOW 

4B   NON-WOODED/HERBACEOUS  481   BERMUDA  CRASS 


5.   WATER  5A   STREAMS/CANALS 

5B   LAKES 


.'C 

F.  E  S  1>  '.  0  :  R  S 

5D 

BAVS/ESTUARIES 

6. 

BARREN 

6A 

DRY  SALT  FLAT 

6B 

PFACHFS 

6C 

SANDY/NOT  BEACH 

6D 

BARE  EXPOSED  ROCK 

6E 

STRIP  MINES,  QUARRIES 
AND  GRAVEL  PITS 

6F 

TRANSITIONAL  AREAS 

6G 

MIXED  BARREN  LAND 

7  . 

PERENNIAL 

7A 

PERENNIAL  SNOWFIELDS 

ICE  i  SNOW 

7a 

CLACl ERS 

8. 

SHADOW  I, 
l):^  -'.OWN 

DISCUSSION 

Initial  Level  II  land  cover  interpretation  of  the  104,545  hectare  (230,000 
acre)  area  was  completed  in  eight  hours,  field  evaluation  took  16  hours, 
refined  image  interpretation  is  expected  to  take  eight  hours.  fti  additional 
714,000  hectares  (1.57  million  acres)  have  been  mapped  in  17  hours,  with 
polygon  labeling  expected  to  take  four  hours.  28,213  hectares  (62,069  acres) 
were  mapped  and  labeled  per  hour.  A  soil  scientist  has  estimated  that  mapping 
the  San  Carlos  Reservation's  818,200  hectare  (1.8  million  acres)  on  1:24,000 
orthophoto  quads  would  take  92  hours  at  a  mapping  rate  of  8,893  hectares 
(19,565  acres)  per  hour. 

Comparative  costs  for  initial  land  cover/land  use  mapping  are  shown  in  Table  2 
below  using  the  818,200  hectare  (1.8  million  acre)  San  Carlos  Reservation  as  a 
sample  case: 

Table  2:   Cost  comparisons  for  various  land  cover  mapping  techniques  on  the 
million  acre  San  Carlos  /^pache  Reservation 


TYPE  OF 
IMAGERY 


LANDS  AT  TM 
1:100,000 


ORTHOPHOTO 
1:24,000 


COLOR   AERIAL 
PHOTO   1:15840 


IMAGE 

ACQUISITION 

COSTS 


$1750 


$3240 


(1981)  -  $7852 


Mapping 
Costs,  Land 
Cover/Soils 


Mapping  Hours    29 
Cost/Hour  $12 

Digitizing  Hr    84 
Cost/Hour  $10 

$  Total  Mapping    $1188 


92 


$12 


$1104 


110 


$12 


$1320 


PROJECT  COST 


$2938 


$4344 


$9172 


COSTS/ ACRE 


$.0016 


$.0024 


$.00509 


A  comparison  of  acquisition  costs  of  TM,  orthophoto  and  color  aerial  imagery- 
shows  a  two  to  four  fold  difference  in  cost.  Mapping  hours  vary  from  66%  to 
75%  less  time  than  those  of  traditional  procedures.  Using  orthophoto  and 
color  photography  the  data  capture  stage  would  come  at  a  later  point  of  the 
inventory  process.  The  TM  mapping  and  data  capture  was  33  percent  less  than 
the  opthophoto  mapping.  TM  was  69  percent  less  than  color  aerial  photo 
technique.  As  mentioned  above,  a  significant  cost  factor  in  the  TM  cost  per 
acre  is  digitizing  expense,  not  incurred  in  this  instance  for  the  other  two 
data  sources. 


Ground  truthing  of  the  office  generated  map  showed  two  areas  needing  editing. 
Ecotones,  blending  of  vegetative  types  as  elevation,  precipitation  and  aspect 
change,  proved  difficult  to  office  map.  Editing  was  also  needed  in  one  2300 
hectare  (5,000  acre)  area  of  water  flov?ing  over  bare  rock  surrounded  by  bare 
rock  outcrops. 
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When  the  1:100,000  product  was  plotted  on  mylar  and  overlaid  on  a  7.5  minute 
quad,  accuracy  with  contours  and  the  green  forest  vegetation  areas  was 
estimated  to  be  greater  than  90%,  producing  a  satisfactory  product  for  a  field 
crew  to  refine  as  the  survey  continues. 

CONCLUSION 

At  Order  IV  this  technique  provides  a  fast,  accurate  method  for  developing 
initial  land  cover/land  use  information.  The  end  product  is  a  MOSS  GIS  data 
theme  rather  than  a  hard  copy  product  needing  to  be  captured.  When  the 
mapping  is  completed,  technical  staff  are  left  with  a  hard  copy  image  that  can 
be  used  to  map  grazing  utilization,  delineating  geologic  structures,  provide  a 
June,  1985  point-in-time  record  for  large  scale  land  use  activities  and  be 
used  for  other  interpretive  activities. 

Future  uses  for  this  data  theme  at  San  Carlos  include  prescription  burn  fuel 
type  maps,  vegetation  trends,  firewood  cutting  locations,  water  sources  for 
livestock  and  wildlife,  habitat  types  for  big  game,  potential  sites  for  rare 
and  endangered  plant  species,  probable  locations  of  cattle  for  aerial  stock 
counts,  probable  locations  for  existing  big  game  species  as  well  as  potential 
sites  for  big  game  plantings  to  name  several  future  uses. 
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The  development  of  hich  performance,  cost  effective  oersonal  microcomauters  has 
permitted  the  aaplication  of  low  cost  hardware  m  tne  area  of  Geograonic  Information 
System  (GIS)  analysis.  The  Map  Overlay  and  Statistical  System  (MOSS)  is  one  exarnpie 
of  an  existing  GIS  system  with  a  large  user  base  wnicn  has  been  ported  to  a  IBM 
compatible,  Personal  Computer  (PC)  Disk  Operating  System  (DOS)  environment.  The 
result  is  a  tremendous  potential  for  mexoensive  distributed  GIS  processing  to  be 
implemented  in  organizations  already  using  GIS  technology  or  for  the  introouction  of 
GIS  technology  to  organizations  which  previously  have  not  been  aDle  to  afford  such 
technoloay.  These  developments  have  stimulated  much  interest.  This  paner  draws  uaon 
recent  experiences  in  the  development  and  testing  of  PC-MOSS  to  describe  the  current 
status  of  MOSS  in  the  PC  environment.  Minimum  system  hardware  reouirements  are 
described  as  well  as  high-end  maximum  performance  systems.  The  current  status  of 
individual  commands  is  discussed,  detailing  what  potential  users  can  expect  from 
MOSS  as  a  GIS  analysis  tool  in  the  PC  environment.  Potential  future  develooments  are 
described  as  they  relate  to  increased  functionality  of  the  PC-MOSS  system.  Future 
systems  and  configurations  are  addressed  in  light  of  current  develooments  in  PC 
hardware  and  software.  The  paper  is  accompanied  by  a  demonstration  of  PC-MOSB  on  a 
high  performance  DOS  workstation  which  exhibits  the  functionality  of  tne  system  and 
provides  a  first  hand  look  at  its  use. 

INTRODUCTION 

Recent  developments  in  PC  technology  have  addressed  the  serious  limitations  to 
technical  work  once  inherent  in  small,  inexpensive,  single  user  computer  systems. 
Furthermore,  the  trend  shows  no  sign  of  ending.  PCs  continue  to  get  faster,  nrovide 
greater  storage  capacity,  and  interface  with  more  inexpensive,  hign  quality  graphics 
peripheral  devices. 

The  Bureau  of  Land  Managements  (BLM)  Denver  Service  Center  (DSC)  is  currently 
developing  a  PC  based  version  of  MGSS  m  response  to  a  need  exaressed  ay  the  U.S. 
Army  Corp  of  Engineers.  Current  technology  for  single  user  computers  permits  cost 
effective  access  to  GIS  technology  in  organizations  whicn  previously  might  not  have 
justified  the  cost  of  a  GIS  aaproach.  In  addition,  the  use  of  inexpensive  technology 
may  prove  useful  as  front-end  workstations  in  organizations  whicn  operate 
minicomputer  based  GIS. 


HARDWARE  DEVELOPMENTS 

The  PC  was  once  a  relatively  exoensive,  slow  and  technically  limited  computer, 
Largely  used  for  office  automation  tasks  and  only  the  simplest  of  technical  data 
processing,  it  became  a  popular  means  of  addressing  those  needs.  The  original  PCs 
had  little  to  offer  in  the  area  of  graahics  capabilities.  Tecnnical  work  was  seldom 
performed  on  these  computers  because  of  their  relatively  slow  processing  soeeds,  the 
lack  of   large  data  storage  devices,  and  the  lack  of  professional  quality  FORTRAN  77 

comai lers. 

1 

In  recent  years  all  of  these  limitations  have  been  addressed.  The  original  PC  which 
used  a  Drocessor  speed  of  4.66  megahertz  has  given  rise  to  3£  bit  processors  runnmc 
at  speeds  of  up  to  16  megahertz.  DOS  has  remained  the  oaeratmg  system  under  wnich 
all  of  these  computers  have  run,  thus  providing  upward  comoat idi 1 ity.  Large  data 
storage  devices  are  now  routinely  used  with  PCs.  Fixed  disk  drives,  once  commonly 
seen  with  capacities  of  121  and  £0  megabytes,  Are  now  often  as  large  as  4^)  megabytes. 
Third  party  hardware  vendors  can  supply  fixed  disks  u3  to  several  hundred  megabytes 
in  size  and  optical  storage  devices  are  now  available  which  can  exceeti  that 
capacity. 

Porting  MOSS  to  the  PC-DOS  environment  has  become  possible  because  of  these  and 
other  developments.  Interest  in  converting  MOSS  to  a  FORTRAN  77  standard  set  of  code 
has  also  facilitated  the  movement  of  MOSS  code  to  PCs.  The  result  is  an  oooortunity, 
evidenced  by  this  first  effort  to  move  MOSS  to  the  PC,  to  provide  GIS  technology  on 
the  most  widely  used,  mass  production  processors  available  to  date.  This  will  make 
GIS  technology  available  to  many  who  previously  could  not  afford  it. 

The  developments  which  have  made  this  work  possible  are  not  over.  There  continues  to 
be  profound  changes  in  what  technical  users  expect  of  PCs  and  vendors  continue  to 
respond  with  ever  increasing  performance  and  data  storage  capacities.  The  future 
looks  promising  for  those  interested  in  performing  GIS  processing  in  a  single  user 
workstation  environment. 

HARDWARE  REQUIREMENTS 

Although  running  PC-MOSS  requires  a  PC  hardware  configuration  beyond  that  typically 
used  for  office  automation,  the  requirements  are  similar  to  that  used  in  many 
technical  fields  using  PC  technology. 

The  minimum  hardware  configuration  for  PC-MOSS  is  as  follows: 

IBM  compatible  PC/XT 

640  kb  Memory 

XXXa7  Math  Coprocessor 

360  kb  Floppy  disk  drive 

£0  mb  fixed  disk 

500  X  £00  araphics  card  and  monitor  (color  or  mono) 


In  the  interest  of  increased  processing  speeds  arid  higher  auaiity  granhics  a 
Dreferred  hardware  configuration  is  as  follows: 

IBM  compatible  PC/AT  (8  MHz  or  faster) 

64i2i  kb  Memory 

XXX87  Math  Coprocessor 

i.£  mb  Floppy  disk  drive 

40  mb  fixed  disk 

750  X  350  Hercules  compatible  card  and  monochrome  monitor 

The  executabies  for  PC-MOSS  occupy  approximately  5  mb  of  fixed  disk  soace.  Users  of 
PC-MOSS  should  give  due  consideration  to  their  data  snace  requirements  before 
deciding  on  an  appropriate  fixed  disk  capacity. 

Beyond  this  configuration  there  is  much  that  can  be  done  to  further  enhance  the 
performance  of  PC-MOSS.  Use  of  higher  performance  PCs  can  result  in  significant 
reductions  in  processing  times  for  many  tasks.  PC-MOSS  has  been  successfully  run  on 
IBM  PC/AT  compatibles  running  at  speeds  up  to  12  MHz  and  there  is  no  indication  that 
it  would  not  run  successfully  at  16  MHz. 

SOFTWARE  REQUIREMENTS 

In  addition  to  an  aopropriate  version  of  DOS,  running  PC-MOSS  reauires  a  Tektronix 
graphics  terminal  compatible  device  driver  for  the  PC.  Such  software  interprets  all 
instructions  being  written  to  the  PC  console.  When  these  instructions  can  be 
interpreted  as  Tektronix  instructions,  the  console  is  put  into  Tektronix  graohics 
terminal  emulation  mode.  Tektronix  PLOT10  instructions  are  correctly  interpreted  and 
the  appropriate  vectors  drawn  on  the  console  screen.  Use  of  such  software  enables 
MOSS  software  to  be  moved  to  the  PC  environment  without  changes  to  the  graphics 
output  routines.  This  simplifies  the  conversion  process  and  minimizes  changes 
required  to  the  minicomputer  versions,  thus  simplifying  the  task  of  software 
maintenance  on  a  variety  of  computer  architectures. 

CURRENT  CAPABILITIES 

The  original  intention  of  PC-MOSS  was  to  provide  a  subset  of  the  MOSS  vector 
processing  commands  in  the  PC  environment.  PC-MOSS  offers  a  subset  (aoaroximately 
40)  of  the  MOSS  vector  data  processing  commands  users  are  familiar  with  from  the 
Data  General  environment.  These  are  the  only  capabilities  available  at  this  time. 
There  is  no  digitizing,  projection,  raster  processing  or  cartographic  output 
capabilities  available  at  this  time  as  part  of  PC-MOSS. 


The  following   specific  MOSS  vector  data  processing  commands  are   currently  available 
in  PC-M0S5: 

PC-MOSS  COMMANDS 


ACTIVE 

BSEORCH 

DEVICE 

FREQUENCY 

LENGTH 

OPEN 

PROXIMITY 

SELECT 

SUBEDIT 


AREA 

BUFFER 

DISTANCE 

GENERATE 

LIST 

OVERLAY 

QUERY 

SHADE 

WINDOW 


ATTRIBUTE 

COMPUTE. 

ERASE 

IMPORT 

LPOVER 

OVERLAP 


REPORT 
SIZE 


"ATTDESCR 

DATABTEST 
EXIT  FREE 

HELP  L 

MERGE       NUMBER 

PERIMETER 
RESET        SAVE 
STATUS  SUBEAT 


AUDIT 
DELETE 

LEGEND 

PlDT 


ZOOM 


Although  this  list  provides  only  a  small  subset  of  the  MOSS  caoabilities  users  have 
become  accustomed  to,  the  level  of  interest  in  PC-MOSS  is  high.  If  PC-MOSS  becomes 
widely  used  it  is  likely  that  some  users  will  pool  resources  to  develop  more 
capabilities  as  well  as  a  public  domain  system  for  digitizing  and  for  cartographic 
output.  Such  a  system  might  be  based  upon  existing  minicomputer  software  such  as  the 
Automated  Digitizing  System  (ADS),  Analytical  Mapping  System  (AMS),  and  Cartographic 
Output  System  (COS). 

PERIPHERAL  SUPPORT  AND  INTERFACES 

At  this  time  the  only  peripheral  support  provided  by  PC-MOSS  is  printer  and  graphics 
peripheral  support  provided  by  the  Tektronix  device  driver  software.  Some  such 
software  will  support  dot  matrix  printers  as  graphics  devices;  others  will  also 
support  desktop  plotters.  All  graphical  output  from  PC-MOSS  at  this  time  is  in  the 
form  of  screen  dumps  from  the  console  screen. 


The  lack  of  a  direct  canability  for  map  digitizing,  projection  changes,  and 
cartographic  output  constitutes  a  major  drawback  to  the  use  of  PC-MOSS.  The  MOSS 
IMPORT  command  provides  one  mechanism  for  entering  map  data  into  PC-MDSS-  Data  from 
other  PC  based  digitizing  programs  could  be  converted  to  the  MOSS  IMPORT  format  for 
use  in  MOSS.  An  interface  to  a  scan  digitizing  capability  has  been  descriaed 
elsewhere  (Maslanik  and  Szajgin).  Any  data  transfer  capability  between  a 
minicomputer  running  MOSS  and  a  PC  running  PC-MOSS  would  permit  transfer  via  tne 
IMPORT  format.  A  tape  driver  interface  for  the  PC  or  a  serial  communications  link 
would  provide  the  necessary  capability.  Unfortunately,  the  MOSS  EXPORT  command  is 
not  available  in  PC  MOSS.  This  precludes  such  a  simple  approach  to  moving  i'^OSS  data 
into  other  PC  systems  (such  as  CAD  systems)  for  cartographic  outout.  At  this  time, 
such  and  undertaking  requires  converting  the  MOSS  data  directly  into  a  format  usable 
by  the  target  system.  The  map  projection  software  is  also  not  available  m  PC-KDSS. 
This  limits  PC-MDSS  in  the  area  of  cartographic'  manipulat ions.  Future  devsloaments 
may  address  these  shortcomings. 


PROGROMMING  ENVI RDNMEMT 

PC-irnSS  was  develoDed  using  IBM  Professional  FORTRfliM  77  (Ryan-McFarland  FGRTRfiN  77). 
This  compiler  offers  the  features  to  make  porting  from  the  minicomputer  environment 
possible.  The  compiler  requires  use  of  an  XXX87  math  coprocessor.  The  GIS  front- 
end/user-interface  is  written  in  Microsoft  FORTRAN  rather  than  IBM  Professional 
F.ORTRflN  77.  This  permitted  the  development  of  individual  PC-MOSS  commands  as 
separate  executables  which  can  be  soawned  processes  from  tne  Microsoft  FORTRflN 
driver.  This  has  advantages  from  both  the  developmental  and  applications 
perspectives  of  PC-MOSS. 

P  set  of  software  tools  for  use  in  the  development  and  maintenance  of  PC-MOSS  was 
also  developed.  These  tools  consist  of  DOS  . BflT  command  files  which  simolify  the 
tasks  frequently  done  during  software  development.  Two  major  areas  in  wnich  these 
tools  are  used  is  in  file  management  and  in  the  compilation  and  linking  orocess. 
Such  simple  tools  greatly  assist  the  programmer  in  the  accomplishment  of  routine 
tasks.  In  addition,  another  software  tool  provides  information  regarding  the 
dependencies  among  the  various  MOSS  software  modules.  This  information  makes  tne 
compilation  and  linking  processes  easier  to  manage. 

USER  ENVIRONMENT 

The  PC-MOSS  directory  structure  differs  from  the  Data  General  MOSS  directory 
structure.  PC-MOSS  can  be  executed  with  no  master  directory.  PC-MOSS  creates  a 
separate  .  DT  file  for  each  project  (PROJECTNflME. DT) .  The  POLYGON.  DT  file  is  no 
longer  used.  The  user  creates  a  new  project  by  executing  the  OPEN  command  within  PC- 
MDSS.  The  OPEN  command  then  promots  for  a  project  name.  To  create  a  aroject  catalog 
(PROJECTNfiME. DT) ,  the  OPEN  command  should  be  used  immediately  uoon  creating  a  new 
PC-MOSS  directory. 

When  a  project  name  is  specified  using  the  OPEN  command,  that  arojact  remains  active 
after  leaving  PC-MOSS.  When  MOSS  is  executed  again,  the  last  project  OPENed  becomes 
the  current  project.  Thus  the  Data  General  MOSS  RESTART  command  no  longer  aopiies. 
By  default,  PC-MOSS  is  always  invoked  in  RESTART  mode.  The  user  changes  projects  Dy 
using  the  OPEN  command  or  by  olacing  a  valid  project  name  as  the  first  parame-er  of 
a  new  command  line. 

If  a  master  directory  is  used  for  a  project,  it  must  reside  in  a  DOS  directory  of 
the  same  name  as  the  project.  A  master  directory  must  contain  only  one  .  DT  file 
called  MASTER. DT.  PC-MOSS  also  retains  the  name  of  the  directory  wnich  holes  . DT 
files.  This  difference  permits  PC-MOSS  to  distinguish  between  master  anc  work 
directories.  Master  and  work  directories  must  be  immediately  below  tne  system  (DOS) 
root  (/)  directory. 


rhe  directory  structure  used  for  PC-.'^OSS  is  descriDBd  as  roilows: 

PC-MOSS  DIRECTORY  STRUCTURE 


DIRECTORY  NAME 


DIRECTORY  CDNTEMTB 


/GIS 

/GIS/SRC 

/GIS/OBJ 

/GIS/EXE 

/GIS/LNK 

/GIS/UTL 

/GIS/LST 

/GIS/TEST 

/GIS/TEK 

/GIS/DEV 

/GIS/HELP 

/GIS/INTRFflCE 


The  PC-MOSS  system 

Final  FORTRAN  77  Source  Code 

Object  Modules 

Executable  Modules 

Link  Modules 

Utility  Command  Files 

Compiler  Listings 

Test  Data  Files  and  .  DT  Files 

Tektronix  Routines 

Developmental  Source  Code 

User  HelD  Files 

User  Interface  Routines 


BETft  TESTING 


PC-MOSS  is  currently  undernoing  Beta  testing,  flpproxirnately  ten  sites  were  chosen  tt 
test  the   software  prior  to  neneral  release.  It  aonears  that  the  PC-MOSS  software  i; 


performing  well   although  some   problems  remain, 
scheduled  as  a  realistic  test  for  the  software. 


Pi  small   aoDli cat  ions 


jro.iBct 


Some  problems  have  been  encountered  with  the  use  of  PC-MOSS  on  certain  IBM  PC-fiT 
compatible  computers,  oarticularly  high-performance  models  whicn  run  at  higner 
processing  speeds.  These  problems  appear  to  be  related  to  the  Tektronix  graphics 
terminal  device  driver  used  and  do  not  aoDear  to  be  problems  witn  PC-MOSS  itself. 
Examples  of  the  type  of  problem  observed  include  the  computer  "hanging"  when  the  end 
of  a  screen  of  text  is  reached  in  the  MOSS  session  and  non-functioning  cursor  keys. 
It  is  not  known  if  these  problems  are  related  to  the  processor  speeds.  memory 
conflicts,  or  some  other  source.  They  can  most  likely  be  avoided  by  not  using  the 
particular  computers  on  which  they  occur  or  by  using  another  Tektronix  graphics 
terminal  device  driver. 

hIGH-END  SYSTEMS 


In  addition  to  the  minimum  and  suggested  requirements  for  hardware  cescrioed  above, 
some  users  may  have  a  need  to  perform  a  hign  prooortion  of  soonist icatea  analysis 
using  PC-MOSS.  This  may  be  a  potential  problem  due  to  excessive  processing  times. 
Furthermore,  for  large  applications  the  minimum  requirements  will  not  provice 
sufficient  data  storage  space. 

PC  technology   has  developed   into  a   market  place  in  it's  own  ricnt.  ComDatiDle  and 
third  party   vendors  are   competing  to   claim  their   share   of   a   large   cemand.   a 


Drincioal  area      of  comoetition   is  that 


:if  performance.   Recent  distriDution 


using  the  Intel  80586  processor  running  at  a  speed  of  16  MHz  is  one  examDle.  These 
processing  speeds  are  paralleled  by  large  increases  in  cata  storage  caoacity  and 
access  speeds.  Much  of  the  work  performed  during  the  final  stages  of  PC-MOSS 
development  and  testing  were  performed  on  high  performance  PCs  running  at  soeaoB  of 
UD  to  1£  MHs. 


Use  of  these  hign-pErformance  PCs  with  large  data  storags  capacities,  hign- 
resolution  graphics,  cost  effective  graphics  peripherals  (not  currently  SLipportec), 
minicomputer  communications,  and  a  tape  drive  interface  can  Drovide  a  convenient  and 
powerful  single  user  MOSS  workstation.  The  possibilities  will  only  increase  as  PCs 
get  more  powerful. 

DISTRIBUTION  OF  PC-MOSS 

Although  it  is  not  currently  being  distributed,  PC-MOSS  should  be  generally 
available  in  the  near  future.  Current  plans  include  further  testing  by  BLM  and  the 
addition  of  MOSS  raster  aata  processing  capabilities,  fls  with  other  versions  of 
MOSS,  distribution  of  PC-MOSS  will  be  conducted  througn  BLM-DSC. 

PC-MOSS  will  be  Distributed  with  an  installation  program  wnich  prompts  the  user  for 
diskettes  by  number.  On  360k  diskettes  PC-MOSS  is  distriDuted  on  aDoroximately  13 
sequentially  numbered  diskettes.  On  l.Sm  diskettes  PC-MOSS  is  distributed  on 
approximately  7  sequentially  numbered  diskettes. 

The  software  is  supported  by  user  documentation  which  details  the  differences 
between  PC-MOSS  and  Data  General  MOSS,  and  programmer  documentation  wnic.n  Describes 
the  PC-MOSS  installation  procedures  and  programming  environment. 

FUTURE  DEVELOPMENTS 

In  the  short  term  more  capabilities  will  be  added  to  PC-MOSS.  Immediate  plans  for 
PC-MOSS  include  further  testing  by  BLM  and  the  initiation  of  a  Dort inc/ceveloDment 
effort  for  the  raster  processing  commands. 

Work  is  currently  underway  to  interface  PC-MOSS  with  a  scan  digitizing  system 
(Maslanik  and  Szajgin).  For  some  applications  this  will  permit  a  cost  effective 
alternative  to  manual  digitizing  of  map  data.  Furthermore,  use  of  tne  MOSS  IMPORT 
file  format  can  facilitate  ready  transfer  of  data  from  a  number  of  PC  digitizing 
programs. 

Some  limited  work  has  been  done  to  assess  the  utility  of  PC  oased  Computer  Aided 
Design  (CfiD)  systems  for  use  in  the  cartographic  output  effort  of  a  SIS  project. 
This  appears  promising  as  a  capability  which  could  be  interfaced  witn  PC-MOSS. 

The  PC  CflD  market  continues  to  drive  prices  down  on  high  quality  graphics 
peripherals.  PC  CflD  users  cannot  justify  purchasing  peripherals  wnich  cost  more  tnan 
the  computer  which  drives  them.  For  this  reason,  periaherals  manufacturers  have 
begun  offering  inexpensive  digitizing  tablets,  pen  plotters  and  other  cevicss  wnich 
have  wide  application  in  GIS  processing.  GIS  applications  will  obviously  benefit 
from  these  develooments. 

PC-DOS  computers  continue  to  achieve  greater  levels  of  performance.  For  single  user 
workstations,  some  PCs  can  rival  traditional  minicomputers  for  some  tasks.  f^ore 
increases  in  performance  are  expected,  both  at  the  hardware  level  and  at  the 
operating  system  and  compiler  levels. 

In  the  medium  to  long  term,  PC-MOSS  can  be  expectec  to  orovide  the  kind  of 
processing  capabilities  once  only  available  on  much  larger  and  more  expensive 
computers.  PCs,  graphics  peripherals,  and  compilers  will  add  to  major  increases  in 
both  functionality  and  performance. 
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ABSTRACT 


A  major  cost  associated  with  computer  processing  of  spatial  data  using 
Geographic  Information  Systems  (GIS)  is  the  initial  expense  of  manual 
digitizing.  For  several  years,  scan  digitizing  has  been  under 
investigation  by  numerous  organizations  as  a  cost  effective  alternative 
to  the  manual  digitizing  process.  This  paper  documents  the  steps 
required  to  transfer  data  digitized  using  an  operational  scan  digitizing 
system  into  the  Personal  Computer  (PC)  -  Map  Overlay  and  Statistical 
System  (MOSS).  The  processing  required  to  preview  the  scan-digitized 
data  and  to  re-format  the  data  into  standard  MOSS  IMPORT  files  is 
discussed.  The  scan-digitized  information,  consisting  of  line  and  point 
data,  was  successfully  entered  into  PC-MOSS  and  manipulated  using 
standard  MOSS  functions.  Processing  speed  and  storage  of  the  PC  system 
are  adequate  for  operational  transfer  of  scan-digitized  data  into  PC- 
MOSS.  Additional  work  is  required  to  develop  a  more  sophisticated 
scheme  to  retrieve  polygons  from  the  existing  line-and-point  data 
structure  produced  by  the  scan-digitizing  system. 


INTRODUCTION 

Geographic  Information  Systems  (GIS)  provide  an  efficient  method  of 
manipulating  map  information.  Whether  or  not  a  GIS  is  implemented, 
however,  often  depends  on  the  resources  available  for  map  digitizing  and 
editing.  In  an  attempt  to  reduce  the  cost  and  time  required  to  digitize 
maps,  various  methods  of  automated  data  capture  have  been  investigated. 
Principal  among  these  methods  are  automated  line-following  devices  and 
scan-digitizing  systems.  Recent  improvements  in  scan-digitizing 
technology,  such  as  linear  array  digital  cameras  and  more  effective 
line-following  software,  suggest  that  scan  digitizing  systems  may 
provide  ar\  alternative  to  manual  data  capture  for  some  applications 
(Fain,  1985).  The  objective  of  this  paper  is  to  describe  the 
development  of  a  software  interface  between  the  Personal  Computer  (PC)  - 
Map  Overlay  and  Statistical  System  (MOSS)  and  map  data  captured  using  a 
commercial  scan-digitizing  system,  and  to  discuss  the  limitations  of 
this  approach. 


SCflN-DIGITIZING  SYSTEM 

The  sample  data  set  used  for  this  project  was  supplied  by  Energy  Images, 
Inc.,  Boulder,  Colorado^.  These  data  were  captured  by  Energy  Images, 
Inc.  using  their  commercially-available  SmartScan^M  system.  The 
SmartScan  system  operates  by  converting  a  raster  image  of  a  map 
(recorded  using  a  linear-area  camera)  to  multiple  themes  of  vector 
information.  The  conversion  process  is  primarily  a  software  task,  with 
an  operator  present  to  oversee  the  line-following  and  data  editing 
procedure  (Energy  Images,  1985).  The  quoted  cost  and  time  required  to 
capture  essentially  all  themes  except  contours  from  a  typical  U.S.G. S. 
7.5  minute  quadrangle  using  the  Smartscan  system  is  about  $2M.m  and 
1.5  hours.  ft  detailed  discussion  of  the  SmartScan  system,  as  well  as  a 
review  of  other  scan-digitizing  systems  in  the  market,  is  beyond  the 
scope  of  this  paper. 


SAMPLE  DflTfl  SET 

The  sample  data  set  supplied  by  Energy  Images,  Inc.  consists  of  the 
major  themes  present  on  the  :L5-minute  Cape  Mendocino,  California 
U.S. S. S.  quadrangle  (Fig.  1).  The  features  captured  include  coastline, 
major  rivers  and  streams,  primary  and  secondary  roads,  offshore  breaks 
and  rocks,  triangulation  stations,  landnet,  political  boundaries,  and 
labels.   Coordinates  are  given  in  fractions  of  latitude  and  longitude. 

The  SmartScan  data  set  used  consists  of  a  file  of  80  character  records, 
with  one  record  per  coordinate.  Each  record  contains  a  £0-character 
attribute,  several  identification  codes,  and  the  Latitude/Longitude 
location  of  the  point.  Records  for  line  data  are  grouped  as  "line 
segments";  each  set  of  coordinates  corresponding  to  a  segment  are 
labelled  with  an  identifier  code.  The  number  of  coordinates  per 
segment,  as  well  as  the  sequence?  number  of  an  individual  coordinate 
within  a  segment,  are  stored  in  each  data  record.  The  data  set  used  is 
therefore  in  neither  an  arc-node  nor  "spaghetti"  structure.  Instead, 
the  file  structure  contains  some  arc  information,  but  does  not  record 
locations  of  nodes. 

According  to  recent  discussions  with  Energy  Images,  Inc.,  the  SmartScan 
system  does  not  have  the  ability  to  identify  and  build  polygons.  fill 
features  in  the  sample  data  set  are  recorded  as  either  line  or  aoint 
data..  Polygon-type  features  in  the  data  file,  such  as  the  boundary  of  a 
Coast  Guard  station  and  the  outlines  of  offshore  rocks,  are  represented 
by  a  closed  stream  of  line  coordinates.  With  the  exception  of  one  case, 
the  first  and  last  coordinates  of  the  data  set  for  all  polygonal 
features  checked  are  identical.  In  a  single  case  where  a  boundary  is 
shared  between  features,  the  points  making  up  the  shared  segment  in  each 
feature  are  the  same,  and  the  segment  is  identified  as  a  unique  set  in 
each  coordinate  stream.  Table  1  lists  the  number  of  points  contained  in 
the  sample  data  file  for  the  major  features  digitized.   Table  1  also 


1   Reference  to  a  pav^ticular  oroduct  or  compan 
necessar i  ly  coristitute  an  endorsement. 
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Fig.  1.   Cape  Mendocino  15'  U.S.G.S.  quadrangle  from  which  scan-digitized  data 
were  captured. 


includes  estimates  of  time  required  for  manual  digitizing  of  the  themes 
listed.      These  digitizing  times  were  based  on  the  Analytical  Mapping 
System  (PiMS),   and  were  calculated  using  a  regression  procedure  to 
predict  digitizing  times  as  a  function  of  map  complexity  (Getter  et  al., 
1936). 

TABLE  1.   Number  of  points  per  feature  in  scan-digitized  file,  and 
estimated  time  required  for  manual  digitizing. 

Hydrography  -------  7774  points  (4.5  hrs. ) 

Roads  ----  --  ££85  points  (2.5  hrs.) 

Coastline  --------  1611  points  (1.0  hr.  ) 

Land  Net 654  points  (£.13  hrs.) 

Labels  ----------  491  points  (2.5  hrs.) 

Offshore  Features  -  -  -  -  333  points  (2.5  hrs.) 

Boundaries  --------  95  points  (1.3  hr.  ) 


The  amount  of  detail  captured  for  a  given  line  in  the  scan-digitized 
file  appears  to  be  quite  high,  yielding  a  considerably  greater  number  of 
coordinates  than  would  be  captured  using  a  manual  method.  For  example, 
the  first  two  bends  in  the  Bear  River  east  of  the  river's  mouth  (a  map 
distance  of  about  0.15  inches)  is  digitized  using  a  total  of  20 
coordinates.  The  average  movement  between  coordinates  for  these  £0 
points  are  0.035  inches  and  0.005  inches  in  the  X  and  Y  directions, 
respectively.  Since  the  times  quoted  above  for  manual  digitizing  are 
based  in  part  on  the  number  of  coordinates  given  in  the  scan-digitized 
file,  actual  digitizing  times  using  a  cursor  and  tablet  would  probably 
be  less  than  those  shown.  On  the  other  hand,  the  precision  of  the  scan- 
digitizing  system  permits  a  more  accurate  representation  of  the  original 
map.  This  precision,  and  the  associated  speed  of  the  automated  line- 
following  software,  should  be  particularly  valuable  for  maps  containing 
numerous  complex  polygons.  Additional  study,  such  as  that  described  by 
Jenks  (1979),  is  needed  to  determine  the  most  desirable  precision  of  the 
scanning  system  for  typical  mapping  applications.  For  some  uses,  such 
as  plotting  at  a  small  scale,  it  may  be  worthwhile  to  pass  the  data 
through  a  distance-filtering  routine  to  remove  points  with  distances  of 
travel  below  a  given  tolerance. 


MOSS  IMPORT  FILE  FORMAT 

The  principal  method  of  entering  map  data  into  MOSS  and  PC-MOSS  is  via 
the  MOSS  IMPORT  function.  The  IMPORT  function  translates  coordinate  and 
attribute  data  into  MOSS  file  format,  and  builds  the  necessary  header 
and  data  structure  to  permit  analysis  using  other  MOSS  functions.  The 
IMPORT  function  expects  input  files  to  be  in  a  specific  format  (referred 
to  as  IMPORT  or  ADDWAMS  format),  with  separate  files  for  point,  line, 
and  polygon  data.  IMPORT  files  consist  of  attribute  records  and 
coordinate  records.  Each  item  (or  feature)  is  represented  by  one 
attribute  record,  and  N  coordinate  records,  where  N  represents  the 
number  of  points  used  to  define  the  item.  The  coordinate  count  N  is 
stored  in  the  attribute  record,  which  also  contains  a  number  assigned  to 


the  item  during  the  IMPORT  file  formation  process,  and  ar\  attribute 
field.  Island  polygons  in  IMPORT  polygon  files  are  identified  by  keys 
contained  in  coordinate  records.  Coordinates  in  the  IMPORT  file  can  be 
in  either  latitude/longitude  or  (Universal  Transverse  Mercator)  UTM 
units. 

Based  on  this  brief  description  of  the  file  structures  of  SmartScan 
files  and  MOSS  IMPORT  files,  it  can  be  seen  that  the  scan-digitized  data 
contain  all  the  necessary  information,  including  attributes,  coordinate 
counts,  and  coordinates,  to  build  point  and  line  IMPORT  files.  Although 
the  scan-digitized  files  do  not  specifically  identify  polygons,  the  fact 
that  first  and  last  coordinates  are  repeated  for  polygonal  features 
provides  a  means  of  separating  out  these  features  into  a  polygon  IMPORT 
file.  Unfortunately,  the  scan-digitized  file  provides  no  simple  method 
of  identifying  island  polygons. 


SOFTWARE  REQUIREMENTS 

ft  goal  of  this  work  was  to  develop  a  conversion  scheme  adequate  for 
operational  needs,  e.g.,  the  conversion  should  be  a  fairly  rapid  process 
given  the  type  of  equipment  available.  In  addition,  data  reformatting 
must  require  a  minimum  of  human  interaction. 

With  these  restrictions  in  mind,  Fortran  77  modules  were  developed  to 
perform  the  necessary  conversions  in  file  structure  and  format.  fill 
programs  were  written  using  standard  Fortran  77  conventions,  and  were 
successfully  compiled  and  linked  using  both  Microsoft  Fortran  Version 
4.0  and  IBM  Professional  Fortran. 

Processing  consists  of  two  main  steps.  In  the  first  step,  the  single 
SmartScan  file  is  broken  up  into  separate  point,  line,  and  label  (text) 
files.  During  this  stage,  the  data  are  translated  to  IMPORT  format, 
with  one  attribute  record  per  segment,  and  N  coordinate  records  per 
segment.  The  second  processing  step  divides  each  IMPORT  file  into 
separate  themes  (such  as  political  boundaries,  roads,  hydography,  etc.) 
by  comparing  attribute  codes  to  a  table  prepared  by  the  ooerator  using 
an  interactive  program.  This  step  essentially  duplicates  the  action  of 
the  MOSS  SELECT  function,  but  provides  some  useful  capabilities  outside 
of  MOSS. 

In  addition  to  these  key  tasks,  existing  programs  were  used  to  translate 
the  original  latitude/longitude  coordinates  into  UTM  meters  and  map 
inches,  fls  a  means  of  previewing  the  IMPORT  files  before  entry  into  PC- 
MOSS,  a  relatively  simple  color  graphics  program  was  developed  to  take 
advantage  of  the  display  capabilities  of  the  PC  workstation.  This 
Fortran  program  is  linked  with  a  library  of  graphics  routines  (Enhanced 
Graphics  System^M  by  Filtrex  Research,  Inc.)  containing  display  drivers 
for  Hercules  and  EGP  graphics  devices.  UTM  or  map  inch  data  can  be 
overlayed  and  displayed  in  various  scales  and  in  several  colors  using 
this  software.  In  addition,  data  files  can  be  plotted  on  a  Hewlett 
Packard  (HP)-compatible  Epson  pen  plotter  using  Fortran  plotting 
routines  incorporating  HP  Sraphics  Language  plot  calls. 


RESULTS:   CONVERSION  TO  IMPORT  FILES 

The  computer  system  used  for  all  software  development  and  analysis  is 
described  in  Table  £.  In  order  to  compare  processing  times  with  various 
system  configurations,  several  processing  steps  were  timed  with  the  PC 
set  at  a  processing  speed  of  6  MHz,  then  at  1£  MHz.  Several  steps  were 
also  timed  using  reads  and  writes  to  different  devices.  These  times  are 
summarized  in  Table  3. 


Table  2.   Microcomputer  Work  Station 

Computer  -  -  -  PC's  Limited^M  £86-12  personal  computer.  40 
MB  hard  disk,  l.£  MB  and  360  KB  floppy  disks, 
389  KB  virtual  RAM  disk. 

Processor (s)  -  1£  and  6  MHz  80286,  80287  math-coprocessor. 

Graphics 

Display(s)  -  NEC  GB-1  Multisync  ("enhanced"  EGA,  Hercules) 
graphics  card  with  NEC  13  inch  color  monitor. 
PCs-Limited  Universal  Graphics  Adapter 
(Hercules  monochrome,  CGfl  color)  and  1£  inch 
monochrome  monitor. 

Tape  Drive  Qualstar^M  nine-track  drive  (1600/3200  BPI) 

and  controller. 
Printer/ 
Plotters  -  -  Okidata  MicrolineTM  9£  graphics  printer, 

HP-compatible  Epson  8.5"  X  11"  pen-plctter. 

Approximate  Replacement  Cost  of  System  -----  $7, 800.120 


Table  3.   Time  required  for  coriversion  from  scan-digitined 
to  IMPORT  file  format. 

Transfer  from  tape  to  hard  disk  (12  MHz)   -  £.£5  min. 

Transfer  from  tape  to  hard  disk  (  6  MHz)   ----£. 42  min. 

Conversion  to  IMPORT  format:  Step  1  (1£  MHz, 

output  to  hard  disk)  -------------  £.£5  min. 

Step  1  (6  MHz,  output  to  hard  disk)  -  -  -  -  4.67  min. 

Step  1  (1£  MHz,  output  to  RAM  disk)  -  -  £. 1£  min. 

Step  1  (1£  MHz,  output  to  floppy  disk)  -  -  £.50  min, 

Conversion  to  IMPORT  format:  Step  2  (1£  MHz, 

output  to  hard  disk)  -------------  5.75  min. 

Step  £  (6  MHz,  output  to  hard  disk)  -----  10. 4£  min. 

Division  into  individual  themes  (12  MHz)  -  -  -  -  4.  i28  min. 
Division  into  individual  themes   (6  MHz)  -  -  -  -  B.M   min. 

Conversion  from  Lat./Long.  to  UTM  (12  MHz, 

output  to  RfiM  disk) 3.28  min. 

Conversion  to  UTM  (12  MHz,  to  hard  disk)  -  -  -  3.50  min. 
Conversion  to  UTM  (6  MHz,  to  hard  disk)  -  -  -  -  5.  30  min. 
Conversion  to  UTM  (12  MHz,  to  floppy  disk)  -  -  5.83  min. 

Import  into  PC-MOSS  (MOSS  IMPORT)  (1£  MHz)  1.50  min. 

Import  into  PC-MOSS  (MOSS  IMPORT)   (6  MHz)  2.42  min. 

Total  Processing  Time  for  Sample  Map  (12  MHz, 

output  to  hard  disk) --19.33  min. 


The  SmartScan  data  were  supplied  by  Energy  Images  on  a  1600  BPI  nine- 
track  tape,  and  consisted  of  a  single  data  file  with  80  character 
logical  records,  and  8000  character  physical  records.  The  scan- 
digitized  file  was  deblocked  and  transferred  directly  to  the  PC  hard 
disk  using  the  Qualstar  tape  drive  and  a  file-transfer  utility.  The 
scan-digitized  file  required  about  1,100,000  bytes  of  storage.  This 
file  was  converted  into  separate  IMPORT-format  files  containing  line 
(306,416  bytes),  point  (5,732  bytes),  and  label  data  (7,936  bytes). 
Latitude/longitude  and  UTM  coordinate  versions  of  each  file  were 
created. 

fls  noted  earlier,  the  scan-digitized  files  did  not  specifically  include 
polygon  data.  However,  several  features  coded  as  lines  did  in  fact, 
upon  examination  of  the  coordinate  streams,  form  closed  polygons.  These 
features  were  transferred  to  a  separate  IMPORT  file  which,  with  the 
exception  of  tags  to  designate  islands,  was  identical  to  a  standard 
IMPORT  format  polygon  file. 


Preview  of  the  IMPORT  files  using  the  color  display  and  plotting 
routines  showed  that  the  INPORT-format  data,  and  by  inference,  the 
original  scan-digitized  files,  are  a  good  representation  of  the  base-map 
features.  Lines  and  points  are  accurate  in  location  and  detail, 
although  a  small  number  of  secondary  streams  and  offshore  features  were 
not  captured.  It  is  not  known  if  these  items  were  purposely  omitted 
from  the  original  sample  data  set,  or  if  the  omissions  are  due  to  errors 
in  the  digitizing  or  format -conversion  process. 

The  only  other  problem  noted  in  the  plotted  maps  was  extraneous  lines  in 
the  landnet  data.  The  misplaced  lines  are  due  to  duplicated  coordinates 
in  the  scan-digitized  file  which  essentially  cause  a  "pen-down" 
condition  to  occur  during  movement  from  one  section  to  another. 
Additional  processing  steps  will  be  required  to  remove  these  errors. 
Fig.  £  shows  examples  of  the  hydrographic  and  transportation  themes 
plotted  from  IMPORT  format  files. 

PC-MOSS 

Transfer  of  the  reformatted  files  (point,  line,  and  polygon  data)  into 
PC-MOSS  was  performed  using  the  MOSS  IMPORT  function.  Both 
Latitude/Longitude  and  UTM  coordinate  files  were  successfully  loaded 
using  IMPORT,  although  the  scale  factor  selected  in  IMPORT  had  a 
significant  effect  on  the  Latitude/Longitude  data.  fl  scale  factor  of 
0.021001  yielded  plottable  data.  Subjects  and  items  were  correctly 
identified  and  cataloged  by  IMPORT,  and  the  newly-created  maps 
successfully  added  to  the  project  directory,  fill  MOSS  commands  tested 
performed  correctly  for  the  MOSS  maps  created  from  UTM  data. 
Latitude/Longitude  data  plotted  correctly,  but  ftUDIT  and  AREA  produced 
distances  and  areas  of  0  miles  and  acres.  Fig.  3  includes  MOSS  maps 
plotted  from  the  imported  files.  Fig.  4  shows  examples  of  output  from 
the  AUDIT  command  for  the  hydrography  map  (line  data)  and  the  Coast 
Guard  station  boundary  and  offshore  rocks  (polygons). 

Two  types  of  errors  were  observed  in  the  imported  MOSS  files.  The  most 
obvious  is  a  duplication  of  the  extra  lines  in  the  landnet  file  as 
discussed  earlier.  fl  second  error  occurred  in  the  polygon  file  for 
offshore  rocks.  As  shown  in  the  AUDIT  listing  in  Fig.  4,  "Sharp  Rock" 
has  an  area  many  times  greater  than  the  other  polygons,  and  is  in  fact 
an  error.  This  error  occurs  due  to  an  extra  point  in  the  coordinate 
stream  for  Sharp  Rock.  The  extra  point  is  the  last  coordinate  in  the 
stream,  immediately  following  the  coordinate  that  closes  the  polygon. 
The  problem  was  rectified  by  removing  the  offending  point  using  a  text 
editor. 

DISCUSSION 

The  conversion  from  the  scan-digitized  file  to  IMPORT  format  files 
proved  to  be  a  relatively  rapid  and,  after  initial  software  development, 
efficient  process.  All  the  original  information  in  the  scan-dinitized 
was  maintained,  and  the  imported  maps  were  successfully  processed  within 
PC-MOSS.  With  the  exception  of  several  apparently  extraneous  points, 
the  scan-digitized  information  appears  accurate  and  detailed.  Further 
work  is  required  to  determine  whether  these  points  were  introduced  by  or 
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Fig.  2.   IMPORT-file  versions  of  scan-digitized  data,   (a)  =  hydrography,  (b)  =  transportation  themes. 
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Fig.  3.   PC-MOSS  plots  (screen  dumps)  of  scan-digitized  themes,  (a)  = 
hydrography,  (b)  =  transportation,  (c)  =  land  net,  (d)  = 
conibined  themes. 
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Fig.  4.   Examples  of  tables  (derived  from  AUDIT)  for  line  and  polygon 
scan-digitized  data  imported  into  PC-MOSS. 


incorrectly  handled  in  the  reformatting  software,  or  whether  they  are 
inherent  in  the  scan-digitizing  process.  It  is  also  necessary  to 
determine  why  a  few  features  on  the  base  rnap,  which  were  not  visibly 
different  in  line  type  or  color  from  other  features,  were  not  captured. 

Additional  work  is  required  to  determine  the  best  method  of  constructing 
polygons  from  the  scan-digitized  data.  The  data  file  tested  contained 
examples  of  closed  polygons,  although  they  were  not  identified  as  such. 
For  some  uses,  no  additional  processing  of  the  polygons  may  be  required. 
For  other  cases,  a  more  sophisticated  polygon-handling  system  is  needed. 
Line  segments  shared  by  two  or  more  features  appear  to  be  duplicate 
lines,  thus  eliminating  the  likelihood  of  slivers  inherent  when  the  same 
line  segment  is  digitized  more  than  once  for  separate  features.  Based 
on  these  characteristics  of  the  scan-digitized  data,  a  semi-automated 
editing  and  polygon-closing  scheme  for  the  file  structure  is  in 
development.  It  should  also  be  noted  that  Energy  Images,  Inc.  and  other 
scan  digitizing  firms  are  considering,  and  may  have  already  developed, 
complete  polygon-closing  routines  for  their  systems. 

Processing  time  to  convert  from  scan-digitized  format  to  IMPORT  files 
and  to  enter  these  files  into  MOSS  required  about  £0  minutes.  By 
refining  the  software  and  combining  modules  into  a  single  routine 
requiring  less  reads  and  writes  to  disk,  the  time  needed  might  be 
reduced  by  half.  The  time  necessary  for  the  conversion  and  import  steps 
is  felt  to  be  within  acceptable  limits  for  operational  use. 

With  the  exception  of  the  nine-track  tape  drive,  no  special  equipment  is 
needed  to  operate  PC-MOSS  and  the  format  conversion  software  on  a 
standard  PC-flT  class  computer.  Transfer  of  the  scan-digitized  file  from 
tape  to  the  PC  could  be  accomplished  via  a  communications  link  from 
another  computer  equipped  with  tape  drives,  but  would  be  a  slower 
process.  fin  office  with  many  PC-MOSS  users  (and  several  personal 
computers)  would  best  be  served  by  equipping  one  PC  with  a  tape  drive 
unit  such  as  the  one  described  here.  This  machine  could  be  used  to 
transfer  data  files  from  tape  to  floppy  disks  for  use  in  other  systems, 
and  could  serve  as  a  means  of  entering  other  data  sets  such  as  digital 
elevation  data  and  satellite  imagery,  fl  third  alternative  is  to  use  the 
services  of  an  organization  which  can  convert  between  different  types  of 
storage  media. 

In  summary,  entry  of  scan-digitized  data  into  PC-MOSS  can  be  carried  out 
accurately  with  reasonable  effort  and  cost,  fl  relatively  minor  amount 
of  additional  software  development  is  needed  to  complete  the  conversion 
of  scan-digitized  data  to  ready-to-use  map  files. 

fl  personal  computer  system  equipped  with,  or  with  some  access  to,  a  tape 
drive  is  a  useful  tool  for  GIS  analysis,  and  can  be  used  to  enter  and 
process  data  from  a  variety  of  sources.  Such  systems  may  be 
particularly  valuable  for  use  in  field  offices,  since  MOSS  data  files 
and  maps  can  be  copied  to  disk  and  sent  through  the  mail  to  various 
sites,  where  the  data  can  be  manipulated  and  displayed.  Ongoing 
developments  leading  to  inexpensive  but  powerful  microcomputers, 
integrated  raster  and  vector  processing,  and  less  expensive  methods  of 


data  capture  such  as  scan-digitising,  will  likely  lead  to  new  and  varied 
GIS  applications  in  the  future. 
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ABSTRACT 


The  Long  Range  Facilities  Planning  Group  (ENG-11)  at  Los  Alamos  National 
Laboratory  is  responsible  for  current  and  long  range  land  use  planning  at 
the  43-square  mile  facility  and  for  tracking  the  current  locations  of  all 
laboratory  structures.  These  activities  require  valid  base  maps  and  the 
ability  to  manipulate  geographic  information  in  an  efficient  and 
effective  manner. 

To  meet  this  challenge,  ENG-11  has  developed  land  use  planning 
applications  for  its  computer  mapping  system,  AUTOGIS.  MOSS  is  the 
subsystem  most  often  utilized  by  ENG-ll  for  planning  purposes. 

Currently,  the  Planning  Group  uses  the  system  for  quick  access  to  and 
production  of  map  information  requested  for  utilities  review  and 
investigation;  facilities  siting;  location  and  structure  inquiries; 
previewing  the  visual  impact  of  structures;  and  comparison  with 
information  available  through  other  avenues. 


Applications  in  the  development 
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The  Group  employs  AUTOGIS  as  a  technically  sophisticated  planning 
tool  by  utilizing  Its  mapping  functions  for  planning  purposes. 
Information  currently  available  to  Engineering  Division  and  other 
Laboratory  clients  includes  the  location  of  several  thousand  , 
individual  items:  manmade  features  such  as  roads,  buildings 
(permanent  and  temporary),  utilities  and  communication  cables  (and 
appropriate  easements),  and  archaeological  sites;  and  natural 
features  including  slope,  soils,  and  surface  hydrology.  Most  of  this 
data  has  been  entered  by  digitizing  aerial  photographs;  standards  are 
applied  for  easement  locations  and  buffer  zones. 
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INTRODUCTION 

Los  Alamos  National  Laboratory  is  located  on  the  Pajarito  plateau 
in  north-central  New  Mexico.   The  plateau,  at  an  altitude  of 
about  7,000  feet,  is  cut  by  canyons  and  cliffs  into  long,  finger- 
like mesas;  and  is  bounded  by  the  Rio  Grande,  Santa  Fe  National 
Forest,  Bandelier  National  Monument,  San  Ildefonso  Indian  Pueblo, 
and  the  communities  of  Los  Alamos  and  White  Rock.   [Figure  1] 
The  area  is  rich  in  wildlife  as  well  as  in  archaeological  and 
f ossi 1  remains. 

The  Laboratory  is  divided  into  work  sites  called  technical  areas 
(TA's),  with  about  30  sites  currently  active.   Planners  have 
proposed  a  total  of  some  ^6  TA's,  with  boundaries  generally 
falling  along  cliff  edges  or  canyon  bottoms-   The  Laboratory 
provides  work  space  for  approximately  IE, 500  University  and 
contract  employees  in  some  l-^OO  permanent  buildings, 
transportable  buildings,  and  trailers.   These  include  labs, 
offices,  and  support  facilities  such  as  shops,  utilities  plants, 
fire  stations,  cafeterias,  and  other  facilities  appropriate  to  a 
scientific  community  of  over  12,000  people. 

The  location  and  development  of  facilities,  roads,  and 
infrastructure  is  constrained  by  geographic,  environmental,  and 
programmatic  concerns.   Among  these  constraints  are:   slope  and 
type  of  soil;  geological  fault  zones;  ground  water  and  hydrology; 
wind  direction  and  emission  zones;  impact  on  habitat,  migration 
and  endagered  species  (both  flora  and  fauna);  National 
Environmental  Research  Park  zones  (set  aside  to  provide  a  control 
environment  for  comparison  puposes  when  studying  the  impact  of 
Laboratory  activities  in  other  areas);  explosives  hazard  zones; 
hazardous  waste  storage  and  dispos;al  sites;  fossils  and 
archeological  sites;  security;  safety;  future  expansion; 
infrastructure  and  special  facility  needs;  and  functional 
rel at  ionsh  ips . 

The  Long-Range  Facilities  Planning  Group  is  responsible  for: 

o     long-range  land  use  planning,  including  a  Long-Range 
Site  Development  Plan  and  component  plan  elements; 

o     mid-range  planning  elements  in  a  five  year  time  frame; 

o     current  planning,  including  facility  sitings,  both 
permanent  and  temporary; 
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o     planning  of  site  improvements  such  as  erosion  control, 
setbacks,  and  pedestrian  traffic  patterns; 

O     maintenance  of  Laboratory  maps,  at  a  degree  of  accuracy 
up  to  that  consistent  with  two  foot  contouring 
intervals;  and 

o     maintenance  of  mapping  data  inventories,  including  the 
locations  and  identities  of  all  Laboratory  structures. 

As  the  number  of  Laboratory  employees  and  the  number  of 
structures  has  grown,  this  has  become  an  increasingly  complex 
task,  and  the  need  for  computerized  systems  to  assist  in  storage, 
production,  and  analysis  of  maps  and  related  data  has  become 
increasingly  evident. 

SYSTEM 

To  meet  this  challenge,  the  Planning  Group  has  developed,  over  a 
number  of  years,  land  use  planning  application  strategies  for  the 
various  computer  resources  available  to  the  group.   Lengthy 
systems  research  resulted  in  the  selection  of  the  MOSS  subsystem 
of  AUTOGIS  as  the  most  appropriate  GIS  vehicle  for  Laboratory 
facilities  planning.   Compat ib 1 i 1 i ty  with  existing  hardware  (Data 
General  MV^OOO),  the  low  cost  at  which  it  is  available  as  a 
public  domain  program,  and  the  availability  of  updating  and 
installation  from  Autometric  Inc.,  are  important  considerations. 
More  important  is  its  combination  of  mapping,  multiple  overlay 
capability,  attribute  and  textual  information,  and  logical  search 
capabilities.   Though  developed  with  plant  and  animal  populations 
in  mind,  these  are  powerful  tools  for  tracking  and  planning  the 
distribution  of  buildings  and  other  structures  at  a  facility  like 
Los  Alamos  National  Laboratory. 

MOSS  information  is  available  onscreen  at  seven  workstations. 
Each  workstation  is  comprised  of  either  a  ^000  series  Tektronix 
graphics  console  paired  with  a  Data  General  Dasher  for  text 
display,  or  a  ^100  series  Tektronix  color  graphics  console. 
Information  requests  are    often  responded  to  in  part  with 
hardcopies  of  data  displayed  on  the  screen.   The  '^100  series 
color  graphics  consoles  support  color  hard  copy  units,  and  the 
•^000  series  monochrome  consoles  support  black  and  white  hard  copy 
units.   Needs  for  larger  maps  or  drafting  quality  maps  can  be  met 
by  plotter  output  available  by  means  of  two  Houston  Instruments 
ll"xl7"  eight  pen  plotters  and  a  36"xlE0'  CalComp  1070  series 
four  pen  plotter.   A  Summagr aph ics  digitizer  is  also  available  at 
each  of  three  locations. 

For  planning  related  activities  not  appropriate  to  a  GIS,  we  use 
a  combination  of  other  computer  systems  and  traditional  storage 


Cliffords  page  3. 

and  presentation  methods.   The  Structure  Location  Plan  (SLP)s  for 
instance,  combines  TA  maps  with  indices  of  Laboratory  structures. 
For  the  SLR  index,  we  have  chosen  to  use  Lotus  l-E-3,  which  runs 
on  an  IBM  PC-AT  and  more  easily  accommodates  the  existing  index 
format  than  other  software  we  have  considered  for  the  purpose. 
The  SLP  index  can  be  viewed  onscreen  at  the  IBM  PC-AT  or  printed 
on  an  IBM  Proprinter.   The  index  is  combined  with  maps  produced 
in  MOSS  and  edited  to  conform  to  a  standard  multi-sheet  format, 
and  the  composite  document  is  published  and  distributed  to  groups 
throughout  the  Lab. 

DATA 

Data  currently  in  MOSS  include  planimetric  (several  thousand 
manmade  features  such  as  roads,  buildings,  utilities,  and 
archaeological  sites),  topographical  (contour  data  and  other 
natural  features  such  as  soils  and  surface  hydrology),  and 
planning  (long-range  plan)  maps  entered  as  vector  data.   These 
are  organized  into  projects  by  source  and  purpose,  and  into 
maps  by  geographic  area  and  topic. 

Six  current  projects,  organized  by  data  source  and  purpose, 
contain  planimetric  and  topographic  data  stereo  plotted  from 
photographs  taken  in  1976  and  1986  aerial  surveys,  data  digitized 
from  utilities  base  maps,  long  range  plan  maps,  USA  states  and 
counties,  maps  formatted  for  publication  in  the  SLP,  and  maps 
showing  environmental  hazards.   Most  of  these  maps  were  prepared 
for  our  system  by  outside  firms  contracted  to  produce  the  maps. 
Other  maps  are    digitized  on  site  as  well  as  generated  by  cursor 
or  by  entering  coordinates  from  the  keyboard,  or  by  saving, 
merging,  editing,  or  otherwise  manipulating  existing  maps. 

Within  projects,  maps  arB    organized  by  geographic  area  into 
sheets  or  grids  designated  by  a  numeric  code  included  in  the  map 
name.   The  topic  of  the  map  is  indicated  by  a  letter  code  which 
forms  the  other  half  of  the  map  name.   A  final  letter  generally 
indicates  the  type  of  map.   Thus  033BLDGS.A  is  an  area  (polygon) 
map  of  all  buildings  in  grid  033.   Roads,  buildings,  utilities, 
archeological  sites,  and  other  topics  can  be  selected  and 
overlaid  as  desired,  with  the  window  set  to  any  combination  of 
sheets  or  grids. 

Data  not  now  in  MOSS  include  data  stored  by  traditional  methods 
and  data  stored  in  some  other  system.   SLP  Index  data,  for 
example,  is  stored  in  Lotus  1-2-3,  and  consists  of  structure 
numbers,  descriptions,  locations,  and  comments  for  thousands  of 
individual  Laboratory  structures,  (permanent  and  temporary 
buildings,  bridges  and  retaining  walls,  wells  and  cooling  towers, 
bike  lockers  and  dumpsters,  manholes  and  transformers).   Each 
Laboratory  structure  is  assigned  a  TA  designation  and  number. 
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These  structure  numbers  appear  as  subjects  in  MOSS  maps  and  tie 
maps  and  index  together. 

APPLICATION 

AUT06IS  has  proven  to  be  a  versatile  and  powerful  tool 
appropriate  for  a  wide  range  of  applications,  from  facilities 
siting  and  information  requests,  to  site  maps,  to  facilities 
p lanni  ng . 

When  a  request  is  made  for  the  siting  of  a  facility,  roads  and 
buildings  in  the  immediate  location  are    plotted  on  the  screen  and 
hardcopied.   The  proposed  building  is  added  to  the  map,  and  the 
map  is  distributed  to  those  offices  and  individuals  concerned 
with  the  approval  of  that  siting.   CFigure  Bl        In  conjunction 
with  a  siting  request,  a  hardcopy  of  utilities,  archeo log ical 
sites,  nearby  hazards,  or  a  profile  showing  the  visibility  of  a 
structure  from  neighboring  land  may  also  be  produced  and 
distributed  to  appropriate  parties.   In  this  manner, 
the  review  of  a  proposed  siting  can  be  accomplished  quickly  and 
with  careful  consideration  of  any  mapped  constraints.   The  use  of 
MOSS  also  allows  us  to  respond  quickly  to  requests  for  other 
mapping  information,  such  as  the  coordinate  location  of  a 
building  or  other  structure,  the  location  and  elevation  of  a 
drainage  swale,  or  the  presence  of  underground  utility  lines  in  a 
construction  site. 

The  SLP,  formerly  a  paper  plat  document,  is  being  converted  to  a 
computerized  document.   CFigure  33   Storing  these  maps  in  AUTOGIS 
permits  the  window  and  scale  of  any  map  plot  to  be  changed 
easily.   At  the  same  time,  the  accuracy  of  the  maps  is  enhanced 
by  the  use  of  arial  survey  planimetric  data  as  a  base  source  of 
information.   This  saves  weeks  of  time  often  required   to  redraw 
an  entire  SLP  site  by  hand  when  changing  the  scale,  making 
corrections,  or  updating  a  map.   The  index  pages  for  this 
document,  previously  hand  Leroyed  in  ink  on  mylar,  have  been 
entered  into  LOTUS,  where  they  can  be  easily  edited,  sorted,  and 
formatted  for  publication. 

The  Group  employs  AUTOGIS  as  a  technically  sophisticated  planning 
tool  by  utilizing  its  mapping  functions  for  planning  purposes. 
The  visual  impact  of  individual  structures  can  be  checked  by 
developing  profiles  or  3D  images  CFigure  ^1 ,     and  cell  data  can 
provide  overlays  of  slope  or  other  statistical  map  information. 
CFigure  5]   Long-range  plan  maps,  overlaid  on  existing  structures 
and  topography,  assist  in  planning  the  siting  of  new  structures 
in  locations  compatible  with  planning  goals.   CFigure  6].   A 
variety  of  siting  constraints  can  be  quickly  mapped  and 
considered,  with  standards  applied  to  the  graphic  representation 
of  easement  locations  and  buffer  zones. 
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The  Development  Densities  Study  will  use  MOSS  maps  of  easements, 
buffer  and  security  zones;  existing  boundaries  of  development; 
slopes;  opportunities  and  constraints  to  future  development; 
etc.  to  allow  planners  to  examine  each  area  for  developable 
sites;  to  estimate  the  number  of  people  each  site  can  accommodate 
based  on  available  land  and  existing  infrastructure;  and  to 
estimate  the  cost  of  providing  access  and  utilities  to  each  site 
based  on  the  distance  to  utility  mains,  access  roads,  and 
topography.   The  Laboratory  can  choose  to  predevelop  and  thereby 
encourage  development  in  preferred  locations.   Likewise,  certain 
sites  might  be  restricted  for  development  because  of  an  abundance 
of  archaeological  sites  or  because  development  costs  are  unacceptable- 

In  addition,  a  Working  Site  Development  Plan  will  be  used  as  a 
tool  for  making  and  evaluating  short  range  planning  and 
development  decisions.   Computerized  mapping  will  incorporate  the 
abilities  to  overlay  specific  long-range  plans  and  to  manipulate 
various  development  scenarios.   We  will  thus  be  able  to  more 
clearly  understand  the  ramifications  of  individual  siting 
decisions  on  traffic,  circulation  and  parking?  land  coverage;  and 
functional  adjacencies,  while  increasing  our  ability  to  present 
these  concepts  graphically. 

Future  applications  may  include  the  use  of  MOSS  to  track 
populations  and  traffic  patterns  and  assist  in  planning  road 
configurations  and  space  allocations.   Laboratory  planners 
continue  to  investigate  potential  uses  of  this  powerful 
computerized  planning  tool  in  an  effort  to  streamline  its 
planning  operation  and  maximize  the  potential  of  a  small  staff 
given  an  increasing  demand  for  development  and  a  decreasing 
amount  of  developable  land. 
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Geographic   Information   System   (GIS)   software   offers   many  analytical 
possibilities   to  existing  data  sets  that   have  yet   to   be   explored.      Using 
the   MAPS  system,   mapped   aerial   distributions  of   physical   parameters   can   be 
numerically  modified   by  trigonometric   functions,   powers,   or   log   functions, 
averaged  over   specified  areas,  or   combined  with   other  mapped   parameters 
through   various   numerical   operations   to   produce  maps  of   the   derivative 
physical   parameter.      Additionally,   quantities   can    be   summed   over   areas  or 
summed  by  categories. 

Examples  are   given   where  maps   of   glacier   surface   topography   and   ice 
thickness  are  combined   through   mathematical   formulas   to   yield   a   map  of 
the   flow   direction   of   basal   water   and   again   combined   to   yield   a   map   of 
basal  shear   stress.      These   parameters   have   not   been   expressed   in   map   form 
in   the   past,   but   only  as   numbers   at  specific   locations   or   as   a   series   of 
values  along   a   profile.      The   resultant   maps   allow   the  glaciologist   a   better 


understanding  of  the  aerial  distribution  of  the  basal  water  flow  and  basal 
shear  stress,  and  give  the  engineer  a  rapid  means  of  delineating  under-ice 
drainage  boundaries  for  hydropower  assessment. 

INTRODUCTION 

Understanding  flow  instabilities  and  the  transition  from  "slow"  flow 
(typically  0.1  to  1.0  meters  per  day)  to  "fast"  flow  (typically  1  to  100 
meters  per  day)  in  glaciers  has  been  one  of  the  major  unsolved  problems  in 
glaciology  for  the  last  five  to  ten  years.   Work  on  this  problem  has 
focused  mainly  on  the  role  of  water  at  the  glacier  bed  in  reducing  the 
effective  coefficient  of  friction  and  causing  basal  sliding.   Most  "normal" 
glaciers  are  believed  to  flow  largely  by  internal  deformation  of  the  ice. 
Some  additional  flow  can  occur  in  summer  due  to  basal  sliding  caused  by 
increases  in  the  basal  water  pressure  that  result  from  precipitation  or 
strong  glacier  surface  melt.   These  events  supply  water  to  the  glacier 
plumbing  system  at  a  rate  which  temporarily  exceeds  its  capacity,  causing 
an  increase  in  basal  water  pressure  and  hence  glacier  sliding.   Although 
there  is  considerable  debate  about  the  nature  of  water  flow  at  the  glacier 
bed,  there  is  strong  evidence  that  for  most  normal  valley  glaciers  it  is 
largely  m  a  converging  network  of  channels  with  most  of  the  flow  in  one 
or  two  primary  channels  near  the  center  of  the  glacier.   There  are  two 
physical  principles  controlling  this.  The  direction  of  water  flow  at  the 
bed  of  a  glacier  is  determined  by  the  potential  gradient,  which  is  a 
function  of  the  glacier  surface  slope  and  glacier  bed  slope  and  is 
typically  convergent.  Also,  larger  conduits  tend  to  grow  at  the  expense 
of  smaller  ones,  due  to  greater  heat  dissipation  in  the  larger  ones 
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relative  to  their  wall  area,  which  causes  faster  melting,  and  to  water 
drainage  from  smaller,  higher  pressure  conduits  to  larger,  lower  pressure 
ones.  (Paterson,  1981) 

Contrary  to  this  norm,  visual  observations  of  Capps  Glacier  led  us  to 
believe  that  the  basal  water  flow  might  be  divergent  for  as  much  as  the 
lower  8-12  km  of  this  40  km  long  glacier.   Most  of  the  subglacial  water 
emerges  not  at  the  terminus,  but  in  two  channels  along  the  glacier 
margins  well  upglacier  from  the  terminus  (2  km  up  the  south  side  and  6  km 
up  the  north  side).  Some  water  also  emerges  at  the  terminus  in  numerous 
small  channels  scattered  along  the  glacier  front.  These  observations  are 
all  consistent  with  a  divergent  basal  water  system. 

If  the  glacier  plumbing  system  were  in  fact  to  change  at  some  point  in 
space  from  a  convergent  network  with  most  of  the  water  in  one  or  two 
channels  to  a  divergent  system  with  the  water  more  equally  carried  by 
many  small  channels,  one  might  expect  some  significant  difference  in  its 
dynamic  response  to  changes  in  water  input  as  compared  to  most  "normal" 
glaciers. 

Ice  radar  measurements  of  ice  thickness  were  taken  on  lower  Capps  Glacier 
in  1981  as  part  of  a  volcano  hazards  study  that  included  measuring  the 
snow  and  ice  volume  on  Mount  Spurr,  the  source  of  Capps  Glacier.  As  part 
of  that  study  the  glacier  thickness  was  contoured.  This  and  the  surface 
topography  provided  us  with  the  basic  information  needed  to  construct  a 
three  dimensional  potential  surface  that  would  control  the  direction  of 
basal  water  flow  as  well  as  a  map  of  basal  shear  stress. 
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BASAL  WATER  FLOW  DIRECTION 

The  direction  of  water  flow  at  the  bed  of  a  glacier  is  determined  by  the 
glacier  surface  slope  with  some  influence  from  the  glacier  bed  slope. 
Assuming  that  both  the  surface  slope  and  the  bed  slope  are  less  than 
about  20  degrees  and  that  the  difference  between  them  is  less  than  about 
10  degrees,  the  potential  0  at  any  point  is  approximated  by: 

*  =  *0  +  '5j_g(hs  +  0.1  y) 

where  <^q   is  an  arbitrary  constant,  6-i^  is  the  density  of  ice,  g  is 
acceleration  due  to  gravity,  h^   is  the  elevation  at  the  surface,  and  y  is 
the  elevation  at  the  glacier  bed  (Paterson,  1981).   The  gradient  of  this 
potential  surface  is  the  pressure  gradient  that  drives  water  flow  at  the 
glacier  bed.  The  aspect  of  this  potential  surface  at  any  point  is  the 
direction  in  which  the  pressure  gradient  is  maximized  and  therefore  the 
direction  of  water  flow. 

Surface  topography  was  digitized  using  AMS  from  a  composite  topographic 
map  at  1:50,000  made  from  existing  U.S.  Geological  Survey  Tyonek  B-7 
Quadrangle,  1958  and  Tyonek  B-6  Quadrangle,  1958.  Thickness  contours 
were  digitized  from  a  map  of  ice  thickness  made  from  ice  radar 
measurements  (March,  Mayo,  and  Trabant,  in  preparation).   The  boundary  of 
Capps  Glacier  was  digitized  from  field  maps.  The  boundary  map  was  used  as 
a  mask  in  gridding  the  surface  and  thickness  maps  to  be  used  for  later 
calculations.   The  boundary  was  rasterized  using  POLYCELL.   CONSTANT  then 
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gave  the  resulting  map  a  value  of  1.   Finally,  the  mask  was  formed  by 
CROSSing  the  boundary  map  with  the  constant  map.   The  digitized  surface 
contours  and  thickness  contours  were  rasterized  using  quadrant  GRID  and 
a  matrix  of  11,  and  using  the  mask  to  produce  a  map  of  the  glacier  area 
only. 


Several  attempts  were  made  at  gridding  the  maps  before  the  right 
combination  of  parameters  was  found.   A  100m  x  100m  grid  was  tried  first, 
but  proved  to  be  too  fine  a  grid  m  terms  of  processing  time.   250m  x 
250m  was  found  to  be  a  good  compromise  in  terms  of  processing  time  and 
information  given.   Because  the  digitized  points  were  closer  together 
along  contours  than  between  them,  the  weight  function  was  inappropriate, 
and  the  quadrant  function  was  used.   Several  matrix  sizes  were  tried,  and 
11  proved  to  make  the  smoothest  map. 


The  surface  map  was  SCANned  using  AVERAGE  and  MATRIX  3  to  smooth  the 
data  further.   Edge  effects  were  bothersome,  so  the  glacier  boundary  was 
again  POLYCELLed  and  combined  with  the  surface  contours  to  alleviate  the 
problem.  The  result  was  then  converted  to  meters  using  MATH  to  match  the 
thickness  map.  The  thickness  map  was  subtracted  from  the  surface  map  to 
produce  a  map  of  the  glacier  bed.   A  potential  map  was  then  produced  by 
adding  the  surface  map  to  0.1  times  the  bed  map.   Because  the  potential 
map  is  not  readily  understandable  to  the  layman,  a  map  of  the  direction  of 
water  flow  was  made  by  finding  the  aspect  of  the  potential  surface.  The 
aspect  expresses  the  direction  in  which  something  is  facing;  here,  the 
direction  of  water  flow.   Alternatively,  the  potential  can  be  contoured, 
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and  the  direction  of  water  flow  is  known  to  be  perpendicular  to  the 
contours. 

The  resultant  map  of  water  flow  direction  at  the  base  of  the  glacier 
confirms  the  hypothesis  of  a  divergent  water  flow  under  the  lower  part  of 
Capps  Glacier.   Under  the  upper  part  of  the  glacier,  disregarding  ever- 
present  edge  effects,  the  map  shows  water  flow  travelling  down  the  center 
of  the  glacier  bed.   Under  the  lower  glacier,  however,  the  water  flow 
direction  is  shown  to  diverge  as  predicted, 

BASAL  SHEAR  STRESS 

In  the  simple  laminar  flow  model  that  is  commonly  used  to  study  glacier 
flow,  the  driving  force  for  glacier  motion  is  that  component  of  the 
glacier's  weight  parallel  to  the  plane  of  the  glacier  bed  (here  assumed 
also  approximately  parallel  to  the  plane  of  the  glacier  surface).   If  there 
is  no  sliding  of  the  glacier  on  its  bed,  then  this  component  of  the  weight 
is  balanced  by  and  therefore  equal  to  the  shear  stress  t^j  across  the  base 
of  the  glacier.   The  shear  stress  is  determined  by 

Tb  =  <5gh  sin  oc 

where  T)-,   is  basal  shear   stress,   6   is  density  of   ice,   g   is  gravity,   h   is   ice 
thickness,  and   cc  is  surface  slope  (Paterson,   1981). 

To  produce  a  map  of   basal  shear  stress,   a  map  of  surface  slope  was 
calculated  from   the  map  of   surface  elevations  made   previously,   using 
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SLOPE   with   average  and  matrix   3.      This  map   was   then   converted   to  a  map 
of  slope  in   radians   using   MATH.      The  map  of   ice   thickness   was  multiplied 
by  the  sin   of   the  surface  slope  map  and   several  constants   to  obtain   a  map 
of   basal  shear   stress. 

CONCLUSIONS 

It  is  very   important   philosophically   to   examine   a   sequence   of   spatial 
operations  with   spot   checks  or   even   profile  checks   to  confirm   that   the 
output   is   what   is   expected.      In   most   cases   it   is   a   simple   matter   to   examine 
a  single  cell   value  and  run   a   rough   check  by   hand   calculator.      In   other 
cases  examining  a  series  of  cell   values   along  a  line  or   profile  is 
necessary   to  determine   whether   a   function   is   performing   an   operation   in 
the  expected  manner.      For   example,   when    we   originally   gridded   our 
digitized  contours,   the  gridded   values  did  not   flow  smoothly   between 
contours,   but  seemed  to  be  stepped.      Stepping   was  not   apparent   in   the 
original  data,   so  we  applied  an   AVERAGE   function   to  smooth   out   the  steps 
and  generate  a  grid  of   values  which   we  felt  more  accurately   represented 
the  original  data. 

We  have  found  raster-based  GIS  software  to   be   very   useful  in   producing 
map  views  of   parameters  that  glaciologists  have  formerly  seen   only  as 
isolated  numbers.      Mapped  distributions  of   physical  parameters   can   be 
transformed   using   trigonometric  functions,   powers,   or   log   functions,  and 
they  can  be  combined   using   various  numerical  operations.      Results  can   be 
displayed  in  cell  (raster)  format   or  can   be  contoured.      The  methods  can   be 
applied   to  any  aerially  distributed   parameters.      Specifically,   the   technique 
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was  used  to  confirm  the  hypothesis  that  basal  water  flow  under  Capps 

Glacier  becomes  divergent  m  the  lower  reaches  of  the  glacier,  as  well  as 

to  examine  the  basal  shear  stress  of  the  glacier.   A  diagram  of  the  method 

followed  IS  shown  in  Figure  1. 
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Figure  1.   The  names  in  the  boxes  are  those  of 
maps  produced  using  the  indicated  IIAPS  commands. 
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EVALUATION  OF  SPRUCE  FIR  MORTALITY  IN  THE  SOUTHEAST  UTILIZING 
REMOTE  SENSING  AND  GEOGRAPHIC  INFORMATION  SYSTEM  TECHNOLOGIES 

By:   Charles  W.  Dull,  James  Denny  Ward,  H.  Daniel  Brown,  and  W.  H.  Clarke 

USDA  FOREST  SERVICE,  Forest  Pest  Management,  Region  8 

INTRODUCTION 

Concern  about  mortality  in  the  spruce-fir  forest  of  the  southeastern  United 
States  indicated  an  immediate  need  to  conduct  a  survey  to  map  the  extent  and 
severity  of  the  damage.  The  forest  type  is  comprised  of  red  spruce  (Picea 
rubens  Sarg. )  which  occurs  from  North  Carolina  to  Nova  Scocia  and  Eraser  fir 
(Abies  fraseri  [Pursh]Poir. )  which  occurs  only  in  North  Carolina,  Tennessee  and 
Virginia- 

Because  of  the  geography  and  topography  of  the  region,  spruce-fir  forests  in 
the  south  occur  as  a  series  of  island-like  stands  at  high  elevations.  The 
Southern  Appalachian  spruce-fir  is  believed  to  be  threatened  by  an  exotic 
insect  pest,  the  balsam  woolly  aphid  (Adelges  piceae  Ratz.),  by  atmospheric 
deposition  of  pollutants,  and  possibly  by  other  agents.   This  forest  type 
represents  an  extremely  valuable  resource  in  the  south  because  of  its  unique 
natural  beauty  and  its  importance  for  recreation.   It  is  also  considered  by 
many  to  be  a  threatened  species  type  because  of  its  marked  decline  in  area. 

In  addition  to  the  threat  of  the  balsam  woolly  aphid  and  its  impacts,  which  are 
greatest  upon  Eraser  fir,  the  spruce-fir  type  may  be  particularly  vulnerable  to 
atmospheric  deposition  of  pollutants.  These  high  elevation  forest  types 
probably  receive  more  deposition  because  of  the  higher  precipitation  and  cloud 
immersion  than  lower  elevations.   Introduction  of  the  balsam  wooly  aphid  into 
the  southern  Appalachians  provided  a  wealth  of  information  concerning  mortality 
of  spruce  and  fir.  However,  recent  attention  has  shifted  to  the  role  of 
atmospheric  deposition  in  the  higher  elevations.   Red  spruce  may  be  more 
directly  threatened  by  air  pollutants  as  indicated  through  declining  annual 
radial  increment.  The  complicated  nature  of  the  spruce-fir  forest  mortality 
and  the  difficulty  in  establishing  a  cause  and  effect  relationship  indicated  a 
more  pressing  need  for  establishing  baseline  data  on  the  current  status  of  the 
spruce- fir  type  and  its  relationship  to  previously  recorded  geographic 
information  which  may  be  analyzed  through  the  utilization  of  a  geographic 
information  system  (GIS) . 

For  this  project,  aerial  photography  was  acquired  and  interpreted  by  USDA 
Forest  Service,  Forest  Pest  Management,  and  entered  into  a  GIS.   These  data 
were  analyzed  in  relation  to  other  geographic  and  land  use  information  to 
assess  the  mortality  and  determine  the  extent  of  the  spruce-fir  type  in  the 
southeast.   There  is  a  general  transition  from  the  use  of  manual  maps  to 
digitally  encoded  (automated)  maps.   Also,  the  digitally  encoded  geographic 
maps  are  used  to  create  a  data  model  of  geographic  information  in  which  the 
geographic  relationships  and  various  attribute  features  of  geographic  data  are 


represented  in  a  database  environment.  This  project  will  produce  graphics,  and 
more  specifically,  maps  which  may  also  be  models  of  the  analysis  of  various 
interactions  of  forces  at  work  which  may  mold  the  mortality  of  spruce-fir  in 
the  southern  Appalachians. 

There  is  an  increasing  awareness  and  interest  in  the  phenomena  occurring  within 
the  spruce-fir  forests.   This  interest  is  increasing  the  demand  to  develop 
better  ways  to  record,  store,  analyze,  merge,  retrieve  and  display  geographic 
information  to  analyze  these  phenomena.  A  GIS  will  provide  the  most  efficient, 
and  probably  the  only,  means  to  analyze  data  bases  expanding  time  and 
physiographic  regions. 


OBJECTIVES 


1 .  Locate  and  delineate  on  maps  all  red  spruce  and  f raser  fir  in  the 
southern  Appalachians. 

2.  Classify  all  red  spruce  and  f raser  fir  mortality  (percent  of  dead 
standing  trees)  visible  on  aerial  photographic  coverage  in  the  states  of 
Tennessee,  North  Carolina,  and  Virginia. 

3.  Using  a  combination  of  aerial  photographic  sampling  and  ground  checks, 
estimate  losses  within  the  spruce-fir  type. 

4.  Acquire  large  scale  aerial  photography  of  previously  established 
research  plots. 

5.  Develop  and  implement  a  geographic  database  on  the  extent  and  intensity 
of  mortality  in  the  spruce-fir  type  in  North  Carolina,  Tennessee  and 
Virginia. 

6.  Provide  for  comparisons  between  the  extent  and  intensity  of  mortality 
in  relation  to  other  geographic  information  through  the  computer  analysis, 
storage  and  display  of  spacial  (geographic)  information. 


METHODS 
Aerial  Photographic  Acquisition 

Color  infra-red  aerial  photography  at  a  scale  of  1:12,000  of  the  entire  spruce 
fir  type  was  acquired  in  stereo  during  the  summer  (leaf-on  season)  of  1984.   An 
Aero  Commander  68O-F  equipped  with  an  RC-10  camera  and  a  geographic  coordinate 
referenced  navigation  system  was  used  to  acquire  the  photography.   In  the 
winter  of  I985,  true  color  positive  transparencies  were  acquired  in  stereo 
during  the  leaf-off  season  over  the  entire  spruce-fir  range  at  a  scale  of 
1:12,000.  This  photography  was  used  to  modify  the  previously  identified 
boundaries  and  mortality  strata  for  more  specific  and  detailed  evaluations. 
Underflights  were  made  of  previously  established  research  plots  at  a  scale  of 
1:4,000.  All  photography  was  indexed  on  USGS  1:24,000  scale  topo  sheets,  and 
the  photography  and  maps  were  available  to  other  investigators. 


PHOTO  INTERPRETATION 

Boundaries  of  the  spruce-fir  were  delineated  by  skilled  aerial  photographic 
interpreters  directly  on  the  aerial  photographic  transparencies  using  Bausch 
and  Lomb  240  Zoom  stereoscopes  mounted  on  MIM  4  Richards  light  tables.   For 
this  project,  the  spruce-fir  type  was  defined  as  50  percent  or  more  of  the 
dominant  and  codominant  trees  within  the  stand  component  being  spruce  and/or 
fir.   The  boundaries  of  the  type  and  mortality  classes  were  then  transferred  to 
1:24,00  scale  USGS  topo  maps.  Within  the  spruce-fir  type,  the  following 
categories  of  mortality  were  recognized:   (1)  Light  to  moderate  -  less  than 
30%  of  the  standing  dominant  and  codominant  trees  dead;  (2)  heavy  -  30%   to  70% 
standing  dominant  and  codominant  trees  dead;  and  (3)  severe  -  greater  than  70% 
of  the  standing  dominant  and  codominant  trees  dead. 

Stratification  and  Selection  of  Sample  Plots 

During  the  photo  interpretation,  individual  areas  were  sampled  within  the  three 
mortality  classes.   Each  mortality  class  was  randomly  sampled  in  proportion  to 
the  area  of  spruce-fir  type  affected.   A  total  of  232  study  sites,  1/5  acre  in 
size  were  selected  on  Mt,  Mitchell,  Roan  Mountain,  Blue  Ridge  Parkway  and  Great 
Smoky  Mountain  National  Park.  Randomly  selected  1/5  acre  plots  were  viewed  in 
stereo  to  determine  the  number  of  dead  spruce  and  fir  trees  and  the  total 
number  of  spruce  and  fir  trees  visible  in  the  plots. 

Ground  Survey 

A  total  of  132  of  the  1/5  acre  photo  plots  were  randomly  selected  as  plots  for 
the  ground  phase  of  the  evaluation.   Ground  crews  located  the  center  of  the 
photo  plots  on  the  ground  and  marked  them  with  a  metal  stake.   General 
information  such  as  slope,  aspect,  and  the  presence  of  balsam  woolly  aphid  were 
collected.   Starting  at  the  center  of  the  plot,  a  cluster  of  five  sampling 
plots  were  established  with  the  center  stake  serving  as  the  first  point  and  the 
other  four  systematically  arranged  in  a  procedure  similar  to  that  used  by  the 
Southeast  Forest  Experiment  Station,  Forest  Inventory  and  Analysis  work  unit 
and  described  in  their  field  instruction  book.   Data  were  taken  at  each  point 
in  a  variable  size  plot  established  by  a  prism  with  a  basal  area  factor  of 
37-5-  A  fixed  radius  plot  of  6.8  ft.  was  also  established  at  each  point  in  the 
cluster.  There  were  two  sets  of  data  taken  at  each  point  in  the  cluster  on  two 
separate  data  sheets.  The  following  data  was  taken  on  each  tree  for  the 
variable  size  sampling  points:   (1)  species;  (2)  DBH;  (3)  condition;  (4)  total 
height;  (5)  crown  position;  and  (6)  destructive  agents.   On  the  6.8  ft.  radius 
plots  the  following  data  was  taken  on  each  tree  one  inch  DBH  or  greater:   (1) 
species;  (2)  DBH;  (3)  condition;  (4)  destructive  agents;  and  (5)  crown 
position. 

Map  Digitizing  and  Data  Entry 

Maps  were  reviewed  before  data  entry  to  verify  proper  attribute  placement  and 
polygon  closure,  as  well  as  edge  mapping  adjacent  quad  sheets.  The  boundaries 
of  the  spruce-fir  type,  with  the  interior  areas  classified  by  mortality,  were 


digitized  from  2?  quad  sheets.  The  MOSS  family  of  software  was  used  as  the 
GIS  for  data  entry,  analysis  and  display  of  the  data.  The  GIS  is  a  set  of 
software  for  encoding,  transformatting,  analyzing,  and  displaying  map  and  other 
geographic  based  information.  The  system  jLncludes  3  components:   (1)  The 
Analytical  Mapping  System  (AMS)  for  digital  data  entry;  (2)  Map  Overlay  and 
Statistical  System  (MOSS)  and  Map  Analysis  and  Processing  Systems  (MAPS)  for 
data  processing,  analysis  and  display;  and  (3)  Cartographic  Output  System  (COS) 
for  plotting  and  producing  maps.  This  software  was  installed  on  a  MV  4000 
Data  General  minicomputer  with  over  800  megabytes  on  line  disk  storage  capacity 
along  with  a  high  density  tape  drive.  The  system  also  includes  two  large 
format  digitizing  stations  with  graphic  terminals,  color  graphic  display 
stations,  image  display  station,  and  text  terminals.  An  eight-pen  plotter 
provides  map  output  products. 

Primary  data  themes  i.e.,  those  data  layers  which  would  be  found  for  all  topo 
maps  containing  spruce-fir  type,  were  created  as  follows:   (1)  spruce-fir  type 
boundaries;  (2)  spruce-fir  mortality  classification;  (3)  topography;  (4) 
transportation;  (5)  ownership;  and  (6)  drainage.  Secondary  data  themes  which 
included  information  over  portions  of  the  spruce-fir  type  were:  (1)  Study  plot 
locations; (2)  photo  index;  (3)  disturbance  history;  (4)  balsam  woolly  aphid 
protection  boundaries;  (5)  balsam  woolly  aphid  mortality  history;  (6)  balds; 
(7)  spruce-fir  forest  type  (with  hardwood  component)  for  the  Great  Smoky 
Mountain  National  Park;  (8)  railroad-right-of  ways  for  previous  logging 
activities;  (9)  196O  mortality  map  for  Mt.  Mitchell;  and  (10)  other  data  themes 
as  they  become  available. 

AMS  digitizing  allows  the  user  to  enter  information  found  on  the  base  maps  and 
data  overlays  from  base  maps  into  the  system.   It  is  entered  by  means  of  a 
digitizing  tablet  and  a  cursor  which  sends  the  information  to  the  computer 
where  it  is  mathematically  translated  into  a  coordinate  pair  based  on  the  map 
center.  When  the  digitizing  is  completed,  the  map  is  put  through  a  rigorous 
visual  and  analytical  verification  of  the  data.   Completion  of  the  verification 
process  allows  the  data  to  be  moved  into  the  database.   Upon  completion  of 
digitizing  all  data  are  reformatted  for  analysis  by  MOSS. 

A  wide  variety  of  analytical  functions  are  available  in  MOSS  to  analyze 
geographic  information  for  a  variety  of  purposes.   Examples  (by  no  means  an 
inclusive  list)  of  several  different  procedures  which  may  be  followed  are:  (1) 
graphic  overlays  in  which  several  maps  are  overlaid  one  on  another  to  determine 
which  map  elements  coexist  at  particular  locations;  (2)  topological  overlays  in 
which  geographic  elements  from  two  or  more  separate  files  are  joined  or  related 
to  one  another  to  create  an  intergrated  cartographic  file;  (3)  polygonization 
in  which  linked  segments  are  chained  together  to  form  a  polygonal  boundary;  and 
(4)  relational  matching  in  which  two  attributes  are  related  to  one  another  to 
form  the  desired  functional  purpose. 

In  using  maps  in  the  traditional  way,  the  method  has  been  to  look  at  the  maps 
in  order  to  interpret  them.   Geographic  relationships  and  meanings  have 
generally  been  derived  through  the  process  of  human  analysis.   Through  the  use 
of  a  GIS  there  has  been  a  significant  reduction  in  the  need  for  this  human 
analysis.  As  a  result,  a  wide  variety  of  the  interpretations  of  the  data,  with 
a  minimum  of  human  intervention,  can  be  achieved  through  the  use  of  fully 
automated  procedures.   In  addition,  there  are  many  advantages  to  using 
automated  GIS  technologies,  such  as  maintaining  data  in  a  physically  compact 


format,  retrieved  at  much  greater  speed,  and  at  a  lower  cost.  There  is  also 
the  tendency  to  integrate  data  collections,  spatial  analysis,  and  a  decision 
making  process  all  into  one  common  information  base.   All  of  the  automated 
techniques  involve  a  substantial  amount  of  processing  and/or  editing  subsequent 
to  the  initial  data  capture.   These  may  include:  (1)  plotting  or  printing  of 
digitized  coded  data  for  visual  editing;  (2)  topological  checking  to  insure 
correctness  within  data  sets;  (3)  removal  of  concurrent  lines  captured  to 
represent  the  same  map  vector;  (4)  polygonization  of  arc  information  into 
polygons;  (5)  editing  XY  coordinate  data;  and  (7)  edge  map  analysis. 

Map  Production 

The  COS  subsystem  of  the  MOSS  family  of  software  was  used  to  produce  maps 
displaying  the  primary  data  themes  for  all  the  spruce-fir  areas  in  the 
southeast. 


RESULTS  AND  DISCUSSION 

Data  were  analyzed  by  region  of  spruce-fir  type  in  the  southeast  as  follows: 
(1)  Great  Smoky  Mountain  National  Park;  (2)  Blue  Ridge  Parkway; (3)  Roan 
Mountain;  (4)  Grandfather  Mountain;  (5)  Mt.  Rogers /White  Top  Mountain;  and  (6) 
Mt.  Mitchell.   Data  were  also  compiled  to  summarize  conditions  throughout  the 
southeast.  At  this  time,  distribution  of  the  spruce-fir  and  mortality  in 
relation  to  elevation  has  been  the  primary  focus  of  investigations. 
Preliminary  results  are  available  on  the  relationship  of  the  spruce-fir  type 
and  other  geographic  features. 

Maps  displaying  the  distribution  and  the  stratification  of  mortality  in 
relation  to  all  primary  data  themes  were  produced  with  legends  indicating  the 
total  number  of  acres  of  spruce-fir  type  classified  by  mortality.   An  analysis 
of  the  data  for  spruce-fir  mortality  by  region  will  include  the  following  GIS 
analysis:  (1)  mortality  classification  expressed  in  number  of  acres  and 
percent  of  area  by  geographic  region  (Table  1);  and  (2)  acres  of  mortality 
stratified  by  elevation  expressed  as  a  percent  of  total  area  by  region  (Table 
2).  Spruce-fir  mortality  data  analysis, based  solely  on  ground  truth  will 
include:  (1)  percent  of  spruce  and  fir  mortality  classified  by  elevation  for 
each  region  (Table  3) ;  and  (2)  percent  of  the  stand  component  for  spruce  and 
fir  classified  by  elevation  for  each  region  (Table  4). 


TABLE  1.    SPRUCE-FIR  FOREST  IN  THE  SOUTHEAST  CLASSIFIED  BY  MORTALITY 


Geographic  Light 

Area  Acres       % 

Great  Smokey  35,759     73 

Mountain 

National  Park 

Mt.  Mitchell  5,^09     75 

Roan  Mountain  256     17 

Mt.  Rogers/  1,582    100 
White  Top  Mtn. 

Grandfather  Mtn.  659     71 

Blue  Ridge 

Parkway  2,058     37 

TOTAL  ^5.723     70 


MORTALirf  CLASSIFICATION 
Heavy  Severe 

Acres  %  Acres 

2692    6 


% 


289 
583 


4 
38 


0 


124   13 


550   10_ 


4,238 


10.365  21 

1,514  21 

698  45 
0 

145  16 

2^82  52 

15,711  24 


Total 
Acres  % 
48,816  74 


7,212  11 

1,537  2 

1 , 582  2 

928  1 

5.597  10 

65.672  100^ 


Light  =  30  %   standing  dead  dominant  and  codominant  trees 
Heavy  =  30^  -  70^  standing  dead  dominant  and  codominant  trees 
Severe  =  70^  standing  dead  dominant  &  codominant  trees 


TABLE  2.   SPRUCE-FIR  MORTALITY  IN  THE  SOUTHEAST  STRATIFIED  BY  ELEVATION 

4600  ft. 


Mortality  {%   of  Area) 
4600-5200  ft.  5200-5800  ft.  5800-6400  ft. 


Geographic  Region 

Great  Smoky  Mtn 
National  Park 

Mt.  Mitchell 

Blue  Ridge 
Parkway 

Roan  Mountain 

Grandfather 
Mountain 

Mt.  Rogers/ 
White  Top 

Spruce-Fir  Type 
in  the  SE 

L  =    30%   mortality 
H  «    30-70^  mortality 
S  =    70^  mortality 


H 


H 


H 


H 


7   0 


4 
1 

0 
7 

2 

7 


0 
0 

0 
0 

0 
0 


0 

0 
0 

0 
0 

0 
0 


39  2   0   26   3  15 
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TABLE  3.   RESULTS  OF  GROUND  TRUTH  FOR  SPRUCE-FIR  MORTALITY  BY  ELEVATION  STRATUM 

4200-5400  ft.        5400-6000  ft.      6000-6500  ft.         Overall 


Area 


Mt. 


Spruce   Fir 

N   %  N  % 


Spruce    Fir 

N %  N % 


Spruce    Fir 

N %  N  % 


Spruce     Fir 

N %  N  % 


Mitchell  102   10    4  100    83  13   57  23    l8  39    54  72    203  14   115  49 


Roan 


Mountain   17    6   27   67    83   1  181  50    16  13   129  30    II6   3   337  44 


Blue  Ridge 
Parkway    12    0*  l4    0*  128   5  I60  93 

Great 
Smokey 

Mountain  105   13   44  100   l47   6  120  88 
National 
Park 


50*    30*   145   5   177  84 


25   4    14  86    277   9   178  91 


N  =  No.  of  trees  sampled. 
*Insufficient  sample  size. 
_1  /  ^  of  Sampled  trees  dead 

TABLE  4.   SPRUCE-FIR  FOREST  TYPE  STAND  COMPONENT  (PERCENT)  BY  ELEVATION 

STRATUM  FOR  GROUND  TRUTH  SAMPLES 


Area 


4200-5400  ft. 5400-6000  ft. 


Other   S 


Mt.  Mitchell   58    2      40    35   24 


Other 


41 


6000-6500  ft. 


F  Other 


Overall 


F  Other 


22    66     12     41   23 


36 


Roan 
Mountain 

Blue  Ridge 
Parkway 

Great  Smoky 
Mountain 
National 
Parkway 


19   31      50    27   59      14 


21   24      55^   33   42      25 


11    87 


21   62 


63    38     0^    32   39 


52   22     26    43   36     21     64    36     0    48   3 


17 


29 


21 


i/. 

S  = 

F  = 


Insufficient  Sample  Size 
Red  Spruce 
Eraser  Fir 


At  this  point,  severe  mortality  appears  to  occupy  a  greater  proportion  of 
the  area  at  higher  elevations  as  opposed  to  lower  elevations.  These  higher 
elevation  stands  also  contain  a  much  greater  percentage  of  fraser  fir. 
Fraser  fir  mortality,  as  observed  in  this  study,  is  very  consistent  with 
reports  of  published  balsam  woolly  aphid  activity.  A  very  strong 
correlation  between  ground  sample  points  and  aerial  sample  points  was  found. 

It  should  be  noted  that  this  survey  is  a  one-point-in- time  analysis  of 
mortality  within  the  spruce-fir  type  and  certainly  not  a  measure  of 
mortality  over  a  period  of  time.   It  is  known  that  a  spruce  or  fir  tree  may 
stand  for  up  to  20  years  and  still  may  be  visible  on  aerial  photographs. 
Further  investigations  will  be  necessary  to  develop  a  stronger  cause  and 
effect  relationship  to  account  for  mortality  observed  during  this  survey. 

In  general,  the  spruce-fir  type  in  the  southeast  occupies  65,672  acres. 
Seventy-four  percent  of  this  forest  type  was  found  to  occur  on  the  Great 
Smoky  Mountain  National  Park. followed  by  Mt.  Mitchell,  11%;  Blueridge 
Parkway,  10%;  Roan  Mountain,  2%;   Mount  Rogers/White  Top,  2%;    and  Grandfather 
Mountain .  1% . 

Within  the  spruce-fir  type.  70%  of  the  total  area  was  classified  as  light  to 
moderate  mortality  (less  than  30%  standing  dead  trees);  heavy  -  mortality 
occupying  6%  of  the  total  area  (30%  to  70%  dead),  and  24%  of  the  total  area 
classified  as  severe  mortality  (greater  than  70%  dead) . 

The  mortality  classifications  in  the  southeast  are  considerably  different 
than  those  found  in  other  areas  of  the  northeast.  This  difference  in 
classification  is  due  primarily  to  the  extentuating  circumstances  of  balsam 
woolly  aphid  known  to  attack  and  kill  great  numbers  of  Fraser  fir  in  the 
southeast. 
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The  largest  concentration  of  coastal  wetlands  in  the  contiguous 
United  StateSr  nearly  40%  of  the  total  wetlands,  occurs  in  Louisiana. 
Within  the  framework  of  state  govermnent,  one  state  agency  responsible 
for  protecting  and  managing  activities  which  occur  in  these  wetlands 
is  the  Coastal  Management  Division  of  the  Louisiana  Department  of 
Natural  Resources.  As  a  tool  for  making  decisions  concerning  proposed 
activities  and  the  evaluation  of  possible  consequences  of,  or 
alternatives  to,  these  activities,  a  geographic  information  system 
(GIS)  has  been  implemented. 

The  GIS  is  based  on  a  Data  General  MV- 10000  computer  and  uses 
the  public  domain  Map  Overlay  and  Statistical  System  (MOSS)  as  the 
main  software  package  which  provides  information  to  coastal  resource 
analysts  to  aid  in  the  review  of  proposed  activities.  Upon  receipt 
of  an  application  to  conduct  a  regulated  activity  in  the  coastal 
zone,  the  "alS  is  i-seu  to  provide  a  standard  package  of  information 
based  on  the  location  of  tht:  project.  The  data  provided  includes 
types  and  acrecigts  oT  habitat  in  the  vicinity,  changes  in  habitat 
which  have  occurred  over  a  22  year  period,  proximity  of  sensitive 
areas,  unique  habitats,  bird  rookeries,  waterfowl  concentrations, 
and  other  relevant  data  available  in  the  data  base.  Additional 
information  or  analyses  may  then  be  made  available  at  the  request 
of  the  technical  staff  to  address  specific  questions  or  evaluate 
possible  alternative  routes,  sites  or  methods  which  would  result 
in  the  minimum  alteration  or  adverse  impacts  on  Louisiana's  coastal 
wetlands. 

Monitoring  wet'a'.di.  areas  and  updating  the  extensive  map  data 
bare  held  by  the  Coastal  Managoment  Division  is  conducted  using  the 
ERDAS  software  and  LANP5AT  thematic  mapper  data  along  with  aircraft 
borne  high  altitude  tfiematic  mapper  simulator  data  obtained  from 
flights  over  the  coastal  areas.  These  provide  the  capability  to 
use  the  GIS  to  monitor  wetlands  for  the  occurrence  of  unauthorized 
activities.  The  MOSS/ERDAS  interfacing  capabilities  of  the  GIS  can 
also  bd  used  to  update  the  division's  map  collection  and  provide 
current  data  for  use  by  the  technical  staff  in  making  decisions  which 
may  effect  Louisiana's  valuable  coastal  wetlands. 


*Terry  W.  Howey  and  James  H.  Blackmon,  Louisiana  Department 
of  Natural  Resources,  Coastal  Management  Division  P.O.  Box  44487, 
Baton  Rouge,  La.   70804-4487 
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INTRODUCTION 

The  coastal  wetlands  of  south  Louisiana  comprise  approximately 
40%  of  all  wetlands  in  the  contiguous  United  States,  and  consists 
of  about  3.2  million  hectares  of  swamp,  fresh,  brackish  and  saline 
marshes  (Turner  and  Gosselink,  1975).  These  wetlands  are  extremely 
important  to  Louisiana  for  many  reasons:  They  support  very  large 
commercial  and  recreational  fisheries;  they  serve  as  a  nursery  area 
for  many  species  of  fish  and  shellfish;  they  provide  important 
waterfowl  habitat;  they  support  a  major  trapping  industry  for  nutria, 
muskrat,  mink  and  alligator;  they  help  support  an  increasingly 
important  tourist  industry;  they  provide  an  important  natural  barrier 
and  buffer  for  the  forces  of  tropical  storms  and  hurricanes. 

Louisiana's  coastal  wetlands  are  now  disappearing  at  an  alarming 
rate.  It  is  estimated  that  land  loss  in  coastal  Louisiana  is  from 
102  Km2/yr.  (Gagliano  et  al .  1981)  to  as  much  as  130  Km^/yr.  (Salinas 
et  al .  1986)  and  this  rate  appears  to  be  increasing  geometrically. 
This  loss  of  wetlands  can  be  attributed  to  a  variety  of  causes  which 
probably  all  contribute  to  some  loss,  and  may  have  interacted  to 
cause  the  accelerated  loss  observed  in  recent  years.  These  factors 
include  the  loss  of  sediment  input  resulting  from  leveeing  of  the 
Mississippi  River,  land  subsidence,  sea  level  rise,  and  direct  actions 
by  man  such  as  gravity  and  forced  drainage  projects,  fill  projects 
and  canal  dredging. 

Recognizing  the  importance  and  sensitivity  of  the  state's  coastal 
wetlands  and  the  pressures  on  them,  Louisiana  enacted  legislation 
in  1978  for  management  of  the  resources  of  the  coastal  zone.  In 
1980  the  state  program  began  regulating  activities  in  the  state  through 
the  Coastal  Use  Permit  process  under  funding  from  the  NOAA  Office 
of  Coastal  Zone  Management.  Each  year  since  the  permitting  process 
began,  from  1,000  to  2,000  applications  to  conduct  activities  in 
the  Louisiana  coastal  zone  have  been  received.  From  program  approval 
in  October  1980  through  December  1986  CMD  has  processed  a  total  of 
10,414  permit  applications,  conducted  2,920  program  consistency 
determinations  and  investigated  583  reported  unauthorized  activities 
(began  1983). 

With  such  a  large  number  of  applications  over  a  large  geographic 
area,  and  with  a  low  level  of  staffing  for  this  monumental  task, 
CMD  coastal  resource  analysts  cannot  devote  large  amounts  of  time 
to  each  proposed  project.  The  value  of  using  a  geographic  information 
system  as  one  tool  for  making  land  use  decisions  was  recognized  from 
the  inception  of  the  program.  The  establishment  and  use  of  GIS  data 
as  part  of  the  review  process  for  all  activities  requiring  a  Coastal 
Use  Permit  began  in  October  1986  after  six  years  of  concept 
development,  data  base  building,,  hardware  and  software  acquisition 
and  implementation. 

GEOGRAPHIC  INFORMATION  SYSTEM  COMPONENTS 

The  CMD  GIS  is  operated  on  a  DNR  owned  Data  General  MV/IOOOO 
computer  and  peripherals.  Table  1  lists  the  system  hardware  presently 


Table  1.-  Components  of  CMD  GIS 

HARDWARE 

Data  General  MV/10000  CPU  (5  megabytes  memory) 

Disk  drives:  354  MB  non-removable  (1),  277  MB  removable  (3) 

Tape  drive  (1600-6250  bpi ) 

Gould  image  processor  (joystick  and  console  driven) 

deAnza  color  monitor  (image  processing) 

Matrix  color  graphics  recorder 

Calcomp  3100  digitizing  table  (.001  in.  accuracy) 

Tektronix  4014  display  screen 

Tektronix  4611  hard  copy  unit 

Tektronix  4115  color  display  screen 

Tektronix  4695  colorink  jet  plotter 

Anadex  color  scribe  dot  matrix  plotter 

Versatek  8224  electrostatic  plotter  (24  in.) 

Terminals  DB  0460  (10) 

SOFTWARE 

Fortran  77  and  5 

Map  Overlay  and  Statistical  System  (MOSS) 

Analytical  Mapping  System  (AMS)  for  digitizing 

Cartographic  Output  System  (COS)  for  map  output 

Map  Analysis  Procedure  System  (MAPS)  for  map  output 

Earth  Resources  Data  Analysis  System  (ERDAS)  for  image  processing 

Geographic  Referencing  Index  for  locations  of  maps,  aerial  photos, 

satel lite  data 
MOSS  Command  Interface  (MCI) 

DATA  BASES 

Ecological  Characterization  Maps  (USFWS)  for  1956  and  1978  (250 
7.5  min.  USGS  quad  overlays  per  date) 

Ecological  Atlas  (USFWS)  compiled  in  1980  (15  features  from  10 
maps  at  1:100,000)* 

Coastal  Use  Permit,  Consistency,  Violation  tracking  data  from  CMD 
files  (Complied  on  LSU  IBM  SAS,  used  in  MOSS  multiple  attri- 
bute file) 

Louisiana  Natural  Heritage  Program  threatened  and  endangered 
species 

Shore  and  wading  bird  rookeries 

Section,  Township,  Range* 

SCS  Hydrologic  Units  (5,000  to  40,000  acres)* 

SCS  Soil  data* 

*Work  in  progress 


included  in  the  GIS  along  with  the  major  software  packages  and  data 
bases  available. 

PERMIT  REVIEW  PROCESS 

The  use  of  the  GIS  in  the  permit  review  process  begins  the  day 
the  application  for  permit  is  recieved.  After  initial  screening 
of  the  application  for  completeness  and  determination  that  a  permit 
is  needed,  a  standard  GIS  data  package  is  generated.  This  information 
is  generated  by  the  MOSS  Command  Interface,  which  is  software  developed 
for  CMD  by  Decision  Associates,  Inc.,  and  was  designed  to  automate 
MOSS  processing.  The  necessary  information  imput  is  limited  to  the 
geographic  coordinate  of  the  proposed  activity  along  with  an 
indentifying  permit  application  number.  Approximately  70  MOSS  commands 
are  run  automatically  with  no  other  input  from  the  operator.  Two 
types  of  information  are  them  provided  to  the  analyst  to  assist  in 
evaluating  the  application.  The  first  of  these  is  a  compilation 
of  relevant  map  products,  aerial  photographs,  and  landsat  imagery 
held  in  the  CMD  collection  (approximately  1000  maps  and  1500  aerial 
photos)  which  are  likely  to  show  useful  information  about  the  project 
site.  Table  2  shows  an  example  of  the  output  generated.  Important 
features  designed  into  these  tables  include:  site  referencing  from 
map  borders  in  scaled  distances  (mi  and  km)  and  real  distance  on 
the  maps  (in  and  mm),  reference  numbers  and  abbreviations  necessary 
to  locate  hard  copy  and  digital  format  maps,  bordering  maps  and  less 
frequently  used  maps  such  as  navigation  charts  held  in  the  map  and 
photo  collection.  Thus,  quick  and  easy  access  to  all  available  map 
and  photo  resources  is  provided  to  the  analyst  at  the  time  the 
application  is  received  for  review. 

The  second  group  of  data  provided  to  the  analyst  consists  of 
tables  of  acreage  and  habitat  type,  based  on  National  Wetland  Inventory 
(NWI)  classification  for  an  area  within  a  0.8  Km  (0.5  mi)  radius 
of  the  proposed  activity  for  each  of  two  periods  for  which  data  are 
available-1956  and  1978  (Table  3,  top  and  center).  These  tables 
provide  for  the  analyst  an  overview  of  what  habitats  are  present 
at  the  project  site  and  in  what  proportions,  and  what  has  been  the 
trend  in  habitat  change  for  the  22  year  period  between  1956  and  1978. 
A  second  area  table  (Table  3  lower)  provides  a  more  detailed  analysis 
which  shows  what  has  happened  to  habitats  within  the  "impact  area" 
between  the  referenced  times  within  the  subject  area.  Thus,  it  is 
possible  to  determine  what  acreage  of  each  habitat  has  changed  and 
what  it  has  changed  to,  as  for  example  what  acreage  of  estuarine 
marsh  has  been  converted  to  upland  developed  habitat.  This  information 
is  extremely  useful  in  assessing  possible  land  change  trends  and 
potential  cumulative  impact  problems  of  an  area. 

Areas  sensitive  for  any  one  of  a  variety  of  reasons  and 
incorporated  into  the  data  base  are  also  indentified  and  listed  for 
the  project  analyst.  Those  features  include  wildlife  preserves, 
management  areas,  state  parks,  eagle  nests,  bird  rookeries,  sea  turtle 
nesting  areas,  submerged  grass  beds  and  similar  environmental  features 
within  the  project  area. 
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Table  2.  Typical  list  of  maps  and  aerial  photographs  in  the  CMD  col- 
lection which  was  generated  by  the  GIS  Geographic  Referencing  Index. 
For  map  products  the  map  on  which  a  specified  location  (latitude  and 
longitude)  and  the  three  nearest  adjacent  maps  are  listed  with  the 
distance  of  the  subject  site  to  the  border  with  the  adjacent  map  shown. 
Aerial  photography  lists  contain  the  reference  data  for  the  photo  on 
which  the  site  appears  and  also  for  the  eight  surrounding  photos. 
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Table  2.  Continued. 
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Table  3.  Habitat  types  and  acreage  of  each  which  was  present  based  on 
1956  (upper)  and  1978  aerial  photography,  and  the  habitat  change  (lower) 
which  occurred  between  the  two  periods.  Habitat  change  data  based  on 
comparison  of  cell  data  using  10m  cell  size.  Habitat  classification 
uses  National  Wetland  Inventory  designations  based  on  that  described  by 
Cowardin  et.  al .  1979,  and  Wicker  1980. 
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In  addition  to  tabular  data  several  hard  copy  maps  are  generated 
by  the  GIS  and  provided  to  the  analyst  to  aid  in  the  review  process. 
These  include  a  copy  of  the  7.5  min.  USGS  quadrangle  map  depicting 
habitat  types  and  showing  the  "impact  area"  where  the  detailed 
information  discussed  above  is  located  (Figure  1).  The  remaining 
map  products  consist  of  two  large  scale  maps  (Figures  2  and  3)  showing 
the  "impact  area"  and  which  visually  depicts  the  data  shown  on  Table 
3  along  with  locations  of  activities  which  have  received  permits 
from  CMD  to  conduct  work  in  this  area.  If  any  sensitive  environmental 
features  occur  within  the  "impact  area",  another  map  (Figure  4)  is 
generated  which  shows  these. 

The  GIS  generated  data  package  provides  to  the  analyst,  at  the 
beginning  of  the  review  process,,  information  on  available  in-house 
resources,  the  nature  of  the  habitat  and  how  it  is  changing  at  the 
project  site,  and  important  ecological  features  which  may  be  affected 
by  the  proposed  project.  This  information  is  certainly  not  all  which 
is  necessary  to  prepare  a  final  recommendation  concerning  a  proposed 
project.  What  it  does  provide  is  a  starting  point  for  the  review 
process  and,  most  importantly,  this  information  is  provided  for  every 
project  reviewed  by  this  agency  and  is  provided  within  24  hours  after 
receiving  an  application  for  review.  Another  important  contribution 
is  that  hard  copies  of  this  data  are  provided  for  permanent  file 
records  to  support  agency  recommendations.  These  are  also  valuable 
for  correspondence,  meetings  and  other  presentations.  The  standard 
GIS  review  process  has  been  designed  so  that  data  bases  may  be  changed, 
added  to  and  updated.  At  this  time  the  Landsat  thematic  mapper  data 
analysis  is  being  added  to  the  process  to  provide  an  updated  data 
base  to  that  now  available. 

After  initial  review  of  the  standard  GIS  package  it  may  be 
determined  that  additional  or  different  GIS  studies  are  necessary. 
This  can  be  determined  on  a  case  by  case  basis  by  the  analyst  reviewing 
the  project  who  then  works  with  the  GIS  personnel  in  designing 
additional  studies.  These  may  be  as  simple  as  defining  a  different 
radius  for  the  standard  "impact  circle",  or  may  consist  of  conducting 
evaluations  of  several  alternative  locations  for  a  project.  Some 
projects,  such  as  a  pipeline  or  marsh  management  areas  may  require 
special  GIS  studies  because  they  are  linear  or  large  irregular 
features.  The  GIS  can  also  help  locate  and  give  pertinent  information 
on  areas  for  mitigation  projects  by  identifying  suitable  mitigation 
areas  and  providing  quantitative  data  to  support  the  amount  of 
mitigation  requested  to  offset  a  particular  activity.  CMD  has  used 
the  GIS  for  numerous  special  studies  for  these  and  similar  purposes. 
Some  of  these  studies  or  special  projects  include:  Landsat  thematic 
mapper  data  base  creation;  Louisiana  Coastal  Zone  boundary  map; 
commerical  shell  dredge  location  monitoring;  Soil  Conservation  Service 
small  hydrologic  unit  (5000  acres-40,000  acres)  digitization;  Lakes 
Pontchartrain  and  Maurepas,  and  Atchafalaya  Bay  special  management 
areas;  Minerals  Management  Service  onshore  impact  study;  alternative 
route  selection  for  oil  and  gas  facility  site  access  canals. 
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Figure  1.  Example  of  land  use  and  vegetation  cover  (Habitat  Map) 
prepared  from  1978  aerial  photography  and  conforming  to  USGS  7.5  min- 
ute quadrangle  map  to  show  the  complexity  of  digital  maps  used  by  the 
CMO  GIS. 


•9 


\ 


Figure  2.  Example  of  a  0.8  km  (0.5  mi)  "impact  circle"  centered  on  a 
proposed  project  location  and  showing  environmental  conditions  existing 
based  on  1956  aerial  photography.  Star  symbols  show  positions  of  sites 
proposed  for  activities  since  the  state  regulatory  program  began. 
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Figure  3.  Example  of  a  0.8  km  (0.5  mi)  "impact  circle"  centered  on  a 
proposed  project  location  and  showing  environmental  conditions  existing 
based  on  1978  aerial  photography.  Star  symbols  show  positions  of  sites 
proposed  for  activities  since  the  state  regulatory  program  began. 
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IMPACT  AREA 


Figure  4.  Example  of  GIS  map  product  showing  two  environmentally  sen- 
sitive areas  and  a  0.8  km  (0.5  mi)  "impact  circle"  centered  on  a 
proposed  project  site.  All  features  are  georeferenced  to  the  USGS  7.5 
minute  quadrangle. 
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CONSIDERATIONS  IN  GIS  IMPLEMENTATION 

Most  discussions  of  this  type  are  presented  as  sales  talks, 
generally  glossing  over  the  problems  encountered  along  the  way.  CMD 
does  not  employ  any  strictly  computer  personnel  and  as  planners, 
biologists,  and  geographers,  many  interesting  aspects  of  the 
implementation  process  of  a  GIS  have  been  experienced. 

Acquisition  of  funding  is  the  first  problem  to  be  overcome  by 
any  agency.  This  usually  includes  a  conceptual  feasibility  study 
to  outline  a  system.  In  the  case  of  CMD,  several  studies  as  well 
as  data  base  creation  and  remote  terminal  use  preceeded  the  in-house 
system  acquisition.  CMD  initially  invested  about  $1  million  on 
hardware,  software  and  the  data  base  for  the  GIS  now  in  place. 

Speed  and  capacity  in  relation  to  cost  is  a  major  consideration 
in  system  selection.  The  decision  made  is  dictated  by  the  application. 
Unfortunately,  similar  software  packages  cost  more  for  large  systems. 
CMD's  computer  has  a  great  deal  of  capacity  (5  megabytes  of  memory, 
4  disk  drives)  and  CMD  probably  will  remain  the  major  user.  On  a 
daily  basis,  depending  on  projects,  the  system  can  either  be  bogged 
down  or  hardly  used.  As  other  software  and  data  is  added,  the  capacity 
will  probably  be  expanded  even  though  CMD  is  a  relatively  small  agency. 

The  time  from  conception  to  daily  utilization  is  a  factor  normally 
underestimated.  CMD  spent  six  years  involved  in  this  process.  Every 
step  in  the  process  was  complicated  and  required  attention  from 
managers  and  technical  personnel.  One  problem  with  implementation 
is  that  computer  and  software  sales  representatives  often  misrepresent 
their  product  through  ignorance  or  for  other  reasons.  These  problems 
do  not  become  important  until  the  system  is  purchased  and  installed. 
Often  agency  managers  do  not  fully  understand  their  own  requirements 
and  fail  to  ask  the  right  questions.  In  CMD's  experience,  some 
necessary  hardware-software  links  were  not  in  the  system  and  software 
failed  to  do  all  that  it  was  advertised  to  do.  These  problems  occur 
in  both  public  domain  and  private  domain  software.  Also,  the  amount 
of  support  promised  by  the  vendors  often  varies  from  pre-sale  to 
post-sale.  A  top  level  in-house  computer  staff  is  the  only  way  to 
deal  with  many  of  these  problems.  CMD  uses  consultants  with  high 
level  programmers  and  remote  sensing/GIS  specialists  on  staff. 

The  computer  shouldn't  be  acquired  without  an  accurate,  current 
data  base.  Unfortunately,  many  agencies  acquire  the  hardware  and 
software  and  then  discover  that  the  cost  of  acquiring  the  necessary 
data  base  is  not  affordable.  CMD  has  invested  approximately  $300 
K  in  the  present  data  base  and  will  probably  invest  more  over  the 
next  several  years.  The  extensive  and  rapid  loss  of  wetlands  in 
Louisiana  necessitates  possession  of  a  current  data  base.  To  update 
the  existing  U.S.  Fish  and  Wildlife  Service  Ecological  Characterization 
Maps  in  computer  format  would  probably  now  cost  in  excess  of 
$1,000,000.   For  this  reason,  CMD  has  developed  a  Landsat  thematic 
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mapper  data  base  for  coastal  Louisiana.  It  is  hoped  that  this  will 
be  a  satifactory  and  cost  effective  method  for  periodic  data  base 
updates  at  least  for  land  loss  and  land  use  change  purposes.  Initial 
studies  appear  promising. 

Other  costs  are  just  as  important  as  the  initial  funding.  Two 
of  the  primary  on-going  costs  are  maintenance  and  personnel.  CMD 
hardware  and  software  maintenance  costs  are  approximately  $68,000 
each  year.  Computer  personnel  including  operators,  data  entry 
personnel,  programmers,  digitizers,  remote  sensing/GIS-  specialists 
and  managers  are  necessary  to  operate  a  large  system.  CMD  depends 
upon  the  DNR  Information  Processing  Section  to  maintain  and  operate 
the  CPU.  CMD  directly  employs  an  applications  manager,  a  permit 
tracking  technician  and  student  workers  for  digitizing  and  running 
simple  projects.  CMD  uses  consultants  for  programming,  system 
development,  special  projects  and  trouble  shooting.  CMD  has  not 
been  able  to  hire  permanent  personnel  for  the  GIS  due  to  state  funding 
problems,  although  positions  and  funding  have  been  available  through 
the  federal  grant.  If  CMD  loses  GIS  consultant  services,  the  system 
will  suffer  and  adequate  operation  would  be  difficult,  if  not 
impossible. 

Many  agencies  tie  into  existing  systems  with  existing  management. 
Other  agencies  help  purchase  a  system  with  other  groups  or  for  the 
use  of  a  large  department.  In  most  cases,  a  single  group  or  person 
is  assigned  control  of  the  system.  This  entity  is  usually  not 
applications  oriented.  This  makes  use  by  an  applications  group 
difficult.  At  DNR,  Information  Processing  handles  general  management 
of  the  hardware  and  software  and  works  with  other  groups  within  DNR 
to  develop  their  applications.  CMD  is  totally  responsible  for  it's 
applications  use,  acquisition  of  its  hardware  and  software  and 
consultant  contracts.  This  system  is  not  perfect,  but  has  worked 
during  the  first  year  of  operation. 

After  all  of  the  above  mentioned  problems  have  been  faced  and 
dealt  with,  another  critical  problem  still  exists.  This  problem 
is  full  utilization  of  the  GIS  in  the  agency  to  produce  useful  products 
and  improve  the  ability  of  the  agency  to  perform  its  functions.  To 
accomplish  this,  the  system  must  be  accepted  and  understood  by  the 
professional  staff  in  the  agency.  At  CMD,  our  professionals  generally 
have  education  in  the  biological  sciences  or  geography.  Few  have 
any  advanced  computer  or  GIS  education  or  experience.  The  applications 
development  and  de-bugging  of  a  new  system  is  a  time-consuming  and 
frustrating  experience  for  the  computer  neophyte.  Contrary  to  the 
general  computer  hype,  the  GIS  does  not  have  the  ability  to  solve 
all  of  an  agencies  environmental  assessment  problems.  In  some  cases, 
a  GIS  can  cause  more  problems  than  it  solves.  The  solution  is  to 
guide  the  professional  staff  in  understanding  the  possibilities, 
and  just  as  important,  the  limitations  of  the  GIS.  Eventually,  they 
will  utilize  the  system  and  make  recommendations  to  improve  it  in 
ways  which  will  improve  agency  functions.  CMD's  GIS  group  is  presently 
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trying  to  educate  the  staff  on  the  value  that  the  GIS  could  have 

to  CMD  if  fully  utilized.   Projects  are  being  completed  every  day 

and  eventually  the  GIS  should  be  an  integral  and  necessary  part  of 
CMD  activities. 
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4TH  NATIONAL  MOSS  USERS  WORKSHOP 

MAY  18-21,  1987 

PARTICIPANT  LIST 
(as  of  June  09,  1987) 


1.  BOB  ADER 

BUREAU  OF  LAND  MANAGEMENT 
BLDG.  50,  DFC,  P.O.  BOX  25047 
DENVER,  CO    80225-0047 

3.  NORMAN  AMES 

BUREAU  OF  LAND  MANAGEMENT 
P.O.  BOX  1828 
CHEYENNE,  WY    82001 

5.  KEN  ANDRES EN 

BUREAU  OF  LAND  MANAGEMENT 
BLDG.  50,  DFC,  P.O.  BOX  25047 
DENVER,  CO    80225-0047 

7.  SUSAN  BALLENSKI 

BUREAU  OF  LAND  MANAGEMENT 
2850  YOUNGFIELD 
LAKEWOOD,  CO    80205 

9.  FRANK  BLOMQUIST 

BUREAU  OF  LAND  MANAGEMENT 
1719  EDINBURGH 
RAWLINS,  WY    82301 

11.  JEFFREY  BOOTH 

US  FISH  &  WILDLIFE  SERVICE 
1825  VIRGINIA  AVE. 
ANNAPOLIS,  MD    21401 

13.  SCOTT  BRADSHAW 

BUREAU  OF  INDIAN  AFFAIRS 
ALBUQUERQUE  OFFICE,  FORESTRY 
ALBUQUERQUE,  NM    87125 

15.  JOHN  BRECKENRIDGE 
U.S.  NAVY,  NORDA 
CODE  351 
N.S.T.L.,  MS    39529 


1 
I 


17.  DIANE  BURGESS 

COMPUTER  SCIENCES  CORP. 
3100  NW  BUCKLIN  HILL  RD. 
SILVERDALE,  WA    98383 

19.  MICHAEL  CAPRATA 

BUREAU  OF  INDIAN  AFFAIRS 

P.O.  BOX  790 

LAME  DEER,  MT    59043 
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2.  THEODORE  ALBERT 

BUREAU  OF  LAND  MANAGEMENT 
P.O.  BOX  2965 
PORTLAND,  OR    97208 

4.  CLIFF  ANABLE 

BUREAU  OF  INDIAN  AFFAIRS 
P.O.  BOX  560-FORT  APACHE  AG. 
WHITERIVER,  AZ    85941 

6.  WILLIAM  ASTOR 

USBIA  BRANCH  OF  FORESTRY 

P.O.  BOX  209 

SAN  CARLOS,  AZ    85550 

8.  ROBERT  BEWLEY 

BUREAU  OF  LAND  MANAGEMENT 

PO  BOX  1449 

SANTA  FE,  NM    87504 

10.  BILL  BONNER 

BUREAU  OF  INDIAN  AFFAIRS 
7655  W.  MISSISSIPPI  AVE. 
LAKEWOOD,  CO    80226 

12.  EDDIE  BOX 

SOUTHERN  UTE  INDIAN  TRIBE 
PO  BOX  737 
IGNACIO,  CO    81137 

14.  DEWITT  BRAUD 

DECISION  ASSOC,  INC. 
1276  SHARYNWOOD  DR. 
BATON  ROUGE,  LA    70808 

16.  GREG  BRYANT 

COLORADO  STATE  UNIVERSITY 
FOREST  &  WOOD  SCIENCES 
FORT  COLLINS,  CO    80523 

18.  MICHAEL  CANDELARIA 

BUREAU  OF  LAND  MANAGEMENT 
CALLER  SERVICE  4104 
FARMINGTON,  NM    87499 

20.  MICHAEL  CARS ELLA 

TGS  TECHNOLOGY,  INC. 

P.O.  BOX  25047 

DENVER,  CO    80225-0047 


21.  S.  CHOMAS 

TGS  TECHNOLOGY,  INC. 

P.O.  BOX  25047 

DENVER,  CO    80225-0047 

23.  JOSEPH  CHRISTOPHER 
USDI 

306  CLEARWOOD  DRIVE 
SLIDELL,  LA    7045  8 

25.  MIKE  CLEAVES 

PRIME  COMPUTER 

9200  E.  MINERAL  AVE. 

ENGLEWOOD,  CO    80112 

27.  ANNABEL  CLIFFORD 

LOS  ALAMOS  NATIONAL  LABORATORY 
P.O.  BOX  1663  MS  M701 
LOS  ALAMOS,  NM    87545 

29.  DALE  CUMMINS 

BUREAU  OF  LAND  MANAGEMENT 
2850  YOUNGFIELD 
LAKEWOOD,  CO    80205 


22.  CLAUDE  CHRISTENSEN 

U.S.  FISH  &  WILDLIFE 

18TH  &  C  STREETS  N.W.  RD-859 

WASHINGTON,  DC    20230 

24.  VERN  CIMMERY 

APACHE-SITG REAVES  NATL.  FOREST 
P.O.  BOX  640 
SPRINGERVILLE,  AZ    85  938 

26.  WILLIAM  CLERKE 

USDA  FOREST  SERVICE 
17  20  PEACHTREE  RD. 
ATLANTA,  GA    30367 

28.  ROBERT  COLEMAN 

COLORADO  STATE  UNIVERSITY 
FOREST  &  WOOD  SCIENCES 
FORT  COLLINS,  CO    80523 

30.  FRANK  D'ERCHIA 

U.S.  FISH  &  WILDLIFE  SERVICE 
1011  E.  TUDOR  RD. 
ANCHORAGE,  AK    99503 


31.  DAVID  DATER 
NOAH-NDC 

E-GC12  325  BROADWAY 
BOULDER,  CO    80303 


32.  BARBARA  DUGGAN 

TGS  TECHNOLOGY,  INC. 

P.O.  BOX  25047 

DENVER,  CO    80225-0047 


33.  CHUCK  DULL 

USDA  FOREST  SERVICE 
1720  PEACHTREE  ST. 
ATLANTA,  GA    30367 


34.  MIKE  DWYER 

BUREAU  OF  LAND  MANAGEMENT 
2850  YOUNGFIELD 
LAKEWOOD,  CO    80205 


35.  THOMAS  ENGLISH 

USBIA  LAND  OPERATIONS 

P.O.  BOX  209 

SAN  CARLOS,  AZ    85550 

37.  BRUCE  ERICKSON 

USDA,  NEZ PERCE  NATIONAL  FOREST 
RT.  2,  BOX  475 
GRANGEVILLE,  ID    83530 

39.  TRACE Y  FEAGAN 

TGS  TECHNOLOGY,  INC. 

P.O.  BOX  25047 

DENVER,  CO    80225-0047 

41.  MIKE  FIEBACH 

TGS  TECHNOLOGY,  INC. 

P.O.  BOX  25046 

DENVER,  CO    80225-0047 

43.  PATRICK  FRIEBERG 

USDA  FOREST  SERVICE 
HC  62  BOX  600 
WINSLOW,  AZ    86047 


36.  LORI  ERICKSON 

USDA,  NEZ PERCE  NATIONAL  FOREST 
RT.  2,  BOX  475 
GRANGEVILLE,  ID    83530 

38.  TIMOTHY  EVELEIGH 
AUTOMETRIC,  INC. 
5205  LEESBURG  PIKE  #1308 
FALLS  CHURCH,  VA    22041 

40.  GARY  FICKLING 

DBA  SYSTEMS,  INC. 

117  81  LEE  JACKSON  MEML.  HWY 

FAIRFAX,  VA    22033 

42.  JONATHON  FOSTER 

BUREAU  OF  LAND  MANAGEMENT 
2800  COTTAGE  WAY,  FEDL.  BLDG« 
SACRAMENTO,  CA    95825 

44.  GEORGE  FULLER 
AUTOMETRIC 
343  WEST  DRAKE  #105 
FORT  COLLINS,  CO    80526 
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45.  DENNIS  FUZE 

EPA-  CHESAPEAKE  BAY  PROGRAM 
410  SEVERN  AVE.  #109 
ANNAPOLIS,  MD    21403 

47.  SUSAN  GODEAUX 
NOAH-NDC 

E-GC12  325  BROADWAY 
BOULDER,  CO    80  303 

49.  ARMANDO  GUEVERA 

ENVIRONMENTAL  RESEARCH  INST. 
380  NEW  YORK  ST. 
REDLANS,  CA    92373 

51.  DONALD  HALL 

COLORADO  STATE  UNIVERSITY 
FOREST  &  WOOD  SCIENCES 
FORT  COLLINS,  CO    80523 

53.  TERRY  HOWEY 

LOUISIANA  COASTAL  MGMT. 

P.O.  BOX  44496 

BATON  ROUGE,  LA    70810 

55.  LOUIS  IRWIN 

U.S.  FISH  &  WILDLIFE 

18TH    &    C   STREETS    N.W.    RD-859 

WASHINGTON,    DC        20230 

57   SOL  KATZ 

BUREAU  OF  LAND  MANAGEMENT 
BLDG.  50,  DFC,  P.O.  BOX  25047 
DENVER,  CO    80225-0047 

59.  JOHN  KINEMAN 
NOAA-NGDC 

#E-GC-12  325  BROADWAY 
BOULDER,  CO    80303 

61.  ROBERT  KLAVER 

BUREAU  OF  INDIAN  AFFAIRS 
1425  NE  IRVING  BLDG  100  RM  10 
PORTLAND,  OR    97208 

63.  DAVID  LARSON 

BIA  MESCAL ERO  AGENCY 
P.O.  BOX  189 
MESCALERO,  NM    88340 

65.  GABRIEL  LUCISANO 

COLORADO  STATE  UNIVERSITY 
FOREST  &  WOOD  SCIENCES 
FORT  COLLINS,  CO    80523 

67.  RICHARD  LYONS 

BUREAU  OF  RECLAMATION 
23636  N.  7TH  ST. 
PHOENIX,  AZ    85068 


46.  MIKE  GARRETT 

BUREAU  OF  LAND  MANAGEMENT 
BLDG.  50,  DFC,  P.O.  BOX  25047 
DENVER,  CO    80225-0047 

48.  STANLEY  GROCHOWSKI 
STATE  OF  NEW  MEXICO 
P.O.  BOX  2087 
SANTA  FE,  NM    87501 

50.  LAURA  HALL 

ADVANCED  SCIENCES,  INC. 
P.O.  BOX  28007 
LAKEWOOD,  CO    80228 

52.  PAUL  HARRISON 

TGS   TECHNOLOGY,    INC. 

P.O.    BOX    9076 

FORT  COLLINS,  CO    80525 

54.  ANNE  HUNTER 

AUTOMETRIC,  INC. 
343  WEST  DRAKE  #105 
FORT  COLLINS,  CO    80526 

56.  KATHIE  JEWELL 

BUREAU  OF  LAND  MANAGEMENT 
P.O.  BOX  36800 
BILLINGS,  MT    59107 

58.  BRUCE  KEATING 

BUREAU  OF  LAND  MANAGEMENT 
P.O.  BOX  1828 
CHEYENNE,  WY    82001 

60.  LISA  KLAPWYK 

INFOTEC  DEVELOPMENT  INC. 
500  N.E.  MULTNOMAH,  STE.  200 
PORTLAND,  OR    97  232 

62.  GARY  KRAUSS 

DBA  SYSTEMS,  INC. 

117  81  LEE  JACKSON  MEML.  HWY 

FAIRFAX,  VA    22033 

64.  LYNDA  LIPTRAP 

COMPUTER  SCIENCES  CORPORATION 
410  SEVERN  AVENUE  SUITE  110 
ANNAPOLIS,  MD    21403 

66.  DON  LUSE 

BUREAU  OF  INDIAN  AFFAIRS 
316  W.  26TH 
BILLINGS,  MT    59101 

68.  PATRICK  MADIGAN 

BUREAU  OF  LAND  MANAGEMENT 
P.O.  BOX  1828 
CHEYENNE,  WY    82001 


69.  GAIL  MARCH 

7  94  UNIVERSITY  AVE. 
FAIRBANKS,  AK    997  09 


71.  DAN  MARTIN 

BUREAU  OF  LAND  MANAGEMENT 
BLDG.  50,  DFC,  P.O.  BOX  25047 
DENVER,  CO    80225-0047 

7  3.  RANDY  MCKINLEY 

TGS  TECHNOLOGY,  INC. 
13111  W.  ALAMEDA  PKWY. 
LAKEWOOD,  CO    80228 

75.  J.D.  MULLEN 

TGS  TECHNOLOGY,  INC. 

2627  REDWING  DR.,  SUITE  110 

FORT  COLLINS,  CO    80524 

77.  BRUCE  NIERWIENSKI 

U.S.  FISH  &  WILDLIFE  SERVICE 
PATUXENT  WILDLIFE  RESEARCH 
LAUREL,  MD    20708 

79.  KELLY  PARK 

COLORADO  STATE  UNIVERSITY 

707  AZTEC  #B 

FORT  COLLINS,  CO    80521 

81.  JOE  PERRYMAN 

131  WHITE  HARBOR  RD. 
LONG  BEACH,  MS    39560 


83.  BARBARA  PRIEST 

BUREAU  OF  LAND  MANAGEMENT 
825  NE  MULTNOMAH  ST. 
PORTLAND,  OR    97223 

85.  GEORGE  ROHALEY 

USDA-SOIL  CONSERVATION  SERVICE 
P.O.  BOX  2890 
WASHINGTON,  DC    20013 

87.  GENE  ROSENLUND 

GALLEGOS  RESEARCH  GROUP 

4175  HARLAN 

WHEAT  RIDGE,  CO    80033 

89.  JOSEPH  ROWE 

PRIME  COMPUTER 

9200  E.  MINERAL  AVE. 

ENGLEWOOD,  CO    80112 

91.  WILLIAM  RUSH 

BUREAU  OF  LAND  MANAGEMENT 
394  8  DEVELOPMENT  AVE. 
BOISE,  ID    83705 


70.  TYLER  MARRIOTT 

BUREAU  OF  INDIAN  AFFAIRS 
COLVILLE  INDIAN  AGCY.  BOX  222 
NESPELEM,  WA    99155-0111 

72.  JIM  MASLANIK 

GEOSPATIAL  SOLUTIONS,  INC. 
882  E.  LAUREL  AVE. 
BOULDER,  CO    80  303 

74.  GRETCHEN  MEYER 

BUREAU  OF  LAND  MANAGEMENT 
P.O.  BOX  1828 
CHEYENNE,  WY    82001 

76.  CHRIS  NELSON 

USDA  FOREST  SERVICE 

BOX  640 

SPRINGERVILLE,  AZ    85938 

78.  MARK  O'BRIEN 

BUREAU  OF  LAND  MANAGEMENT 

P.O.  BOX  1420 

BATTLE  MOUNTAIN,  NV    89820 

80.  RICHARD  PEARSON 

LOS  ALAMOS  NATIONAL  LABORATORY 
PO  BOX  166  3 

LOS  ALAMOS,  NM    87545 

82.  MARY  POWELL 

U.S.  ARMY  ENGINEER  TOPO.  LAB. 

ATTN:  ETL-GS-AT 

FT.  BELVIOR,  VA    22060-5546 

84.  JERRY  RICKERS 

DBA  SYSTEMS,  INC. 

117  81  LEE  JACKSON  MEML.  HWY 

FAIRFAX,  VA    22033 

86.  STEVEN  ROLPH 

BIA  COLVILLE  INDIAN  AGENCY 

BOX  111 

NESPELEM,  WA    99155 

88.  KEITH  ROUNSAVILLE 

TGS  TECHNOLOGY,  INC. 

P.O.  BOX  9076 

FORT  COLLINS,  CO    80525 

90.  VERNON  RULLI 

US  BUREAU  OF  LAND  MANAGEMENT 
PO  BOX  182  8  MS  924 
CHEYENNE,  WY    82003 

92.  R.  SCHWARTZ 

BUREAU  OF  RECLAMATION 
P.O.  BOX  9980 
PHOENIX,  AZ    85068 


93.  JIM  SCURRY 

U.S.  FISH  &  WILDLIFE 
NASA/sec,  1010  CAUSE  BLVD. 
SLABELL,  LA   70458 

95.  FERN  SHEPARD 

BUREAU  OF  LAND  MANAGEMENT 
2800  COTTAGE  WAY 
SACRAMENTO,  CA    95825 

97.  DAVE  SNEESBY 

LOS  ALAMOS  NATL.  LABORATORY 
MS-M718  LOS  ALAMOS  NATL.  LAB 
LOS  ALAMOS,  NM    87501 

99.  ED  SOMMERS 

BUREAU  OF  LAND  MANAGEMENT 

PO  BOX  1869 

ROCK  SPRINGS,  WY    82902-1869 

01.  DAVID  SORENSON 

BUREAU  OF  LAND  MANAGEMENT 
2850  YOUNGFIELD 
LAKEWOOD,  CO    80205 

03.  FLOYD  STAYNER 

BUREAU  OF  LAND  MANAGEMENT 
BLDG.  50,  DFC,  P.O.  BOX  25047 
DENVER,  CO    80225-0047 

05.  HENRY  STREIFFER 

DECISION  ASSOC,  INC. 
1276  SHARYNWOOD  DR. 
BATON  ROUGE,  LA    70808 

07.  LENARD  STULL 

BUREAU  OF  INDIAN  AFFAIRS 
2800  COTTAGE  WAY 
SACRAMENTO,  CA    95  825 

09.  JOHN  SZAJGIN 

BUREAU  OF  INDIAN  AFFAIRS 
7655  W.  MISSISSIPPI  AVE. 
LAKEWOOD,  CO    80226 

111.  WENDY  TETLEY 

BUREAU  OF  LAND  MANAGEMENT 
BLDG.  50,  DFC,  P.O.  BOX  25047 
DENVER,  CO    80225-0047 

13.    ROBERT   TURNER 

LOS  ALAMOS  NATIONAL  LABORATORY 
P.O.  BOX  1663  MS  M701 
LOS  ALAMOS,  NM    87545 

115.  DANIEL  VISONE 

U.S.  ARMY  ENGINEER  TOPO.  LAB. 

ATTN:  ETL-GS-CD 

FORT  BELVIOR,  VA    22060-5546 


94.  JOHN  SHEFFEY 

BLM,  UTAH  STATE  OFFICE 
324  S.  STATE,  SUITE  301 
SALT  LAKE  CITY,  UT    84115 

96.  MELL  SMITH OUR 

PAN  AM  WORLD  SERVICES,  INC. 

P.O.  BOX  50 

LOS  ALAMOS,  NM    87544 

98.  JOHN  SNOW 

BUREAU  OF  LAND  MANAGEMENT 
2515  WARREN 
CHEYENNE,  WY    82001 

100.  DUANE  SONNENBURG 

BUREAU  OF  LAND  MANAGEMENT 
18TH  &  C  ST.  N.W.  RM.  2444 
WASHINGTON,  DC    20240 

102.  PATRICK  STATA 

WYOMING  GAME  AND  FISH  DEPT 
5400  BISHOP  BOULEVARD 
CHEYENNE,  WY    82002 

104.  ERIC  STRAND 

BUREAU  OF  LAND  MANAGEMENT 
BLDG.  50,  DFC,  P.O.  BOX  25047 
DENVER,  CO    80225-0047 

106.  GILBERT  STUART 

BUREAU  OF  INDIAN  AFFAIRS 
3600  LIME  ST.,  SUITE  722 
RIVERSIDE,  CA    92501 

108.  KARLA  SWANSON 

BUREAU  OF  LAND  MANAGEMENT 

PO  BOX  1869 

ROCK  SPRINGS,  WY    82902-1869 

110.  DAVID  TAYLOR 

BUREAU  OF  LAND  MANAGEMENT 
2850  YOUNGFIELD 
LAKEWOOD,  CO    80205 

112.  GEORGE  TRUJILLO 

LOS  ALAMOS  NATL.  LABORATORY 
P.O.  BOX  166  3  MAIL  STOP  K495 
LOS  ALAMOS,  NM    87545 

114.  LAURA  UMLAND 

FOREST  SERVICE-NICOLET  NAT'L 
68  SOUTH  STEVENS  STREET 
RHINELANDER,  WI    54501 

116.  ROBERT  WALTERMIRE 

TGS    TECHNOLOGY,    INC. 

PO   BOX    907  6 

FORT  COLLINS,  CO    80525 


117.  DANIEL  WEBSTER 

TGS  TECHN0LCX5Y,  INC. 

P.O.  BOX  25047 

DENVER,  CO    80225-0047 

119.  ARCHIBALD  WELLS 
FORESTRY 
PO  BOX  7007 
PHOENIX,  AZ    85011-7  007 

121.  MICHAEL  WHITING 

USDA  SOIL  CONSERVATION  SERVICE 
2121  C  SECOND  STREET  #102 
DAVIS,  CA    95616 

123.  STEVEN  WING 

BUREAU  OF  LAND  MANAGEMENT 
3707  N.  7TH  ST. 
PHOENIX,  AZ    85014 

125.  ROBERT  WYLIE 

DATA  SYSTEMS  WEST 

8089  S.  LINCOLN  ST.  STE.  204 

LITTLETON,  CO    80122 

127.  BILL  YEAGER 

BUREAU  OF  LAND  MANAGEMENT 
3380  AMERICANA  TERRACE 
BOISE,  ID    83706 


129.  CARL  ZULICK 

BUREAU  OF  LAND  MANAGEMENT 
BLDG.  50,  DFC,  P.O.  BOX  25047 
DENVER,  CO    80225-0047 


118.  M.A.  WEISSMAN 

MICROSCIENCE,  INC. 

1048  S.  310  ST.,  STE.  #4 

FEDERAL  WAY,  WA    98003 

120.  BARBARA  WHITE 

U.S.  FISH  &  WILDLIFE  SERVICE 
2627  REDWING  RD. ,  BLDG.  2 
FORT  COLLINS,  CO    80526-2899 

122.  DANIEL  WICKWIRE 

BUREAU  OF  LAND  MANAGEMENT 
P.O.  BOX  2965 
PORTLAND,  OR    97208 


124.  ROBERT  WRIGHT 
BUREAU  OF  LAND 
P.O.  BOX  2965 
PORTLAND,  OR 


MANAGEMENT 
97208 


126.  EARL  WYNNE 

BUREAU  OF  INDIAN  AFFAIRS 
P.O.  BOX  3785 
PORTLAND,  OR    97208 


128.  MON  YEE 
USDA/SCS 

511  NW  BROADWAY  #238 
PORTLAND,  OR    97  209 
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MOSS  USERS  WORKSHOP 
CONFERENCE  EVALUATION 

May  18-21,  1987 


What  is  your  overall  evaluation  of  the  Workshop? 

Excellent  =  7    Good  =  20    Satisfactory  =  1    Unsatisfactory  =  0 

What  did  you  like  most  about  the  Workshop? 

-  Well  organized  and  business-like. 

-  Frank  discussions  about  functionality  of  MOSS. 

-  Kept  well  to  schedule. 

-  Good  paper  presentations.   Constructive  work  group  sessions, 
good  organization. 

-  Paper  presentations. 

-  The  applications  papers  -  although  some  were  too  basic. 

-  Opportunity  to  share  experiences,  ideas,  and  applications  with 
other  users. 

-  The  presentations  of  actual  MOSS  applications. 

-  Micro-Version  of  MOSS  and  new  developments  and  applications 
for  MOSS. 

-  Provided  some  very  good  insight  into  the  correct  status  of 
MOSS  and  uses  made  of  MOSS. 

-  Papers/People. 

-  Combination  of  the  information  presented  in  the  various 
sessions  and  the  users  sessions. 

-  Exchange  of  information,  presentation  of  applications. 

-  Big  picture  of  what  is  going  on  with  MOSS  Users. 

-  Scott  Bradshaw's  presentation.   It  was  concise  and  directed 
to  actually  using  the  programs. 

-  Seeing  how  people  used  MOSS  to  tackle  difficult  problems. 

-  Lots  of  coffee,  Gail  March's  talk,  learning  about  new  software. 

-  The  application  presentations. 

-  Contacts  with  other  GIS/MOSS  Users. 

-  Communication  of  ideas  and  concepts  between  other  agencies. 

-  Papers. 

-  Timing  of  speakers  and  staying  on  time. 

-  Technical  sessions. 

-  Facilities  and  adequate  time  was  allowed  for  each  agenda  item. 

-  Presentations  were  excellent  and  schedule  was  kept  on  time. 

-  Papers  and  coming  together  of  groups  with  better  understanding 
and  support. 


What  would  you  most  like  to  see  changed  for  future  Workshops? 
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-  More  User  presentations. 

-  Coordinate  software/hardware  update  seminars  (hands-on  on  site 
terminals)  with  the  workshop.  _ 

-  Location  and  more  top  level  (management)  representation,  I 

-  Demonstrations  on  use  of  commands/applications.  ■ 

-  Add  some  training  on  procedures  of  interest  to  users;  wider 
range  of  vendors. 

-  The  workshops  at  the  end  should  be  eliminated  or  combined. 

-  Bring  in  hardware  for  hands-on  demonstration. 

-  More  on  specific  uses  of  MOSS  in  solving  management  problems        m 
and  on  the  use  of  some  complex  MOSS/MAPS  commands.  I 

-  Location  to  include  more  restaurants,  stores,  etc. 

-  Addition  of  optional  seminars  to  cover  a  variety  of  topics, 

i.e.  new  commands  review  or  open  session  to  discuss  problems        I 
and  exchange  ideas.  • 

-  More  hands-on,  and/or  problem  related  solutions.   Address 
specific  "how-to"  ideas. 

-  Hold  the  conference  at  a  better  location  on  the  west  side  of 
town. 

-  Length  -  please  shorten  the  conference  to  3  days.  ^ 

-  More  field  projects  illustrations.  ■ 

-  More  detailed  training/papers  concurrently.  " 

-  Better  view  graphs,  if  possible  considering  time  and  budget. 

-  Better  Audio-Visual  setups. 

-  Shorten  workgroup  sessions  -  less  time  was  needed  this  year. 

-  Location  for  better  restaurant  &  shopping  &  activities; 
more  specifics  about  procedures. 


I 


I 
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What  do  you  feel  were  the  highlights  of  the  Workshop?  I 

-  Breakout  sessions. 

-  Frank  discussions  about  functionality  of  MOSS.  ■ 

-  Frank  discussions  of  where  we're  really  at,  and  Dr.  Guevara's  | 
paper, 

-  Learning  about  the  strengths  and  weaknesses  of  MOSS;  the  m 
informal  discussions  with  and  assistance  from  participants;  I 
the  vendor  displays.  * 

-  ERSI  Presentation;  final  group  presentation  (if  carried 
through,  last  year's  were  not). 

-  Sol  Katz  and  meeting  MOSS  Users  from  different  organizations 
and  states.   Also,  the  workgroups  and  discussions  on  how  to 
improve  MOSS,  and  the  workshop  was  well  organized.   Also,  the 
ape  handing  out  frozen  bananas. 

-  Several  interesting  papers,  all  delivered  on  schedule; 
excellent  banquet;  plenty  of  opportunity  to  talk  informally  ^ 
to  other  users;  helpful  suggestions  and  responses  from  other  I 
users.  ■ 
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What  Do  You  Feel  Were  The  Highlights  of  the  Workshop?  (CONTINUED) 

-  The  opportunity  to  get  together  with  others  involved  in  GIS  and 
to  see  what  other  users  are  doing  with  GIS  technology. 

Users,  Management  and  Systems  Sessions. 

-  Workshop  was  well  organized;  good  to  see  the  vendor 
participation;  good  presentations;  a  good  group  discussion  of 
MOSS  problems  and  their  solutions. 

-  Papers:   the  variety  and  quality  of  the  presentations  were 
excellent.   Also,  information  and  needs  which  came  out  of  the 
Users,  Systems,  and  Management  Sessions. 

-  The  presentations  and  the  dedicated  enthusiasm  of  the  Users 
community. 

-  Presentations  and  Workgroup  Sessions. 

-  Continual  exposure  to  concepts,  ideas  and  terminology  is 
extremely  beneficial.  The  ability  to  meet  and  talk  with 
individuals  is  also  helpful. 

-  Cliff  Anable's  presentation;   all  applications  presentations. 

-  Gail  March's  talk  on  subglacial  hydrology. 

-  Good  finale.   Glad  to  see  the  groups  finally  agreeing  on  the 
steps  to  take  in  the  future.   It's  good  that  the  manager  group 
has  organized  and  is  going  to  maintain  communication  with  the 
other  groups. 

-  Multi-agency  discussions. 

-  Presentations  of  field  projects. 

-  Paper  presentations. 

-  Speakers  from  various  parts  of  the  country  and  their  different 
applications;  learning  what  is  happening  at  the  User  level. 

-  Workgroup  sessions. 

-  Individual  group  sessions;  vendor  exhibits. 

-  Discussions  of  prime  conversion  and  break  out  groups  attempt  to 
address  it. 

-  Group  interaction  was  better  and  presentations  were  more 
varied  -  nice  mix  and  high  quality.  Personal  contacts  always 

a  real  benefit  to  participants.   Discussions  on  s/w  status  and 
progress  were  informative.  More  commitment  by  management  this 
year. 

-  Talks;  better  understanding  among  groups. 


How  did  you  first  learn  about  this  Workshop? 

Brochure  =  9    Personal  Contact  =  15    Other  =  4 

Other:   Associates 

Other  GIS/MOSS  Users 
Call  for  papers 
Attending  Previous  Years 


Please  suggest  topics  you  would  like  to  have  presented  at  future 
workshops: 

-  Training  courses;  friendly  users. 

-  Command  instructions. 

-  Class  type  activities;  clarification  of  specific  items. 

-  Additional  items  pertinent  to  MOSS  Users.   More  presentations 
pertaining  to  MOSS  Usage.   Methods  (shortcuts)  around  MOSS 
that  do/do  not  work. 

-  Short  presentations  on  major  software  enhancements  and 
technical  issues,  as  well  as  short  training  sessions. 

-  New  additions  to  MOSS  which  aren't  well  publicized. 

-  Status  of  current  version  of  MOSS,  to  include  a  description 
of  any  new  features  and  commands  available  to  users.   A  list 
from  each  Agency  describing  the  current  projects  or  users  of 
MOSS.   Also,  any  additional  data  available  to  other  agencies  as 
a  result  of  current  projects. 

-  New  MOSS  commands  -  how  they  work.   Also  a  session  on 
clarification  of  existing  commands. 

-  Any  new  commands,  and  how  to  use  them. 

-  Hands-on  demonstrations  of  MOSS  applications  and  commands. 
Also,  more  presentations  from  BLM. 

-  Specific  training  on  different  MOSS  applications. 

-  Concurrent  presentations  in  MOSS,  MAPS,  etc.,  where  both 
systems  and  applications  papers  would  be  used.   Also,  more 
user  specific  applications  in  soils,  forestry,  vegetation 
inventory,  range,  roads,  route  location,  and  other  natural 
resources. 

-  Data  transfer  among  systems. 

-  Some  CIS  management  presentations;  management  problems  and  how 
CIS  was  used  to  solve  them. 

-  Data  General  Support. 

-  Seminars  on  such  topics  as  command  status  with  software. 

-  Seminars  to  cover  the  use  of  new  commands,  exchange  of  macros, 
and  programs  on  documentation. 

-  Use  of  or  accomplishing  analysis  with  more  complex  commands. 
Coverage  and  distribution  of  known  problems  and  ways  to  work 
around  problems. 

-  Presentations  from  software  people  on  what's  in  the  works  for 
development  and  possible  ways  to  get  around  some  of  the  known 
problems. 

-  Different  uses  for  GIS/RS  Technology. 

-  Consider  modules  of  speakers  so  participants  select  from 
1)   applications,  2)  software,  3)  hardware  sessions  -  this 
would  also  create  smaller  groups  to  generate  more  discussion. 

-  Brief  talks  on  major  improvements  to  software. 

-  Similar  categories  to  this  year  (agency  status,  progress 
reports,  status  on  different  versions,  applications,  etc.)  plus 
reports  of  fixes  and  sources  of  different  releases  and  fixes  of 
different  versions;   also  training  or  hands-on  sessions  topics 
(adding  and/or  editing  multiple  attributes,  adding  new  maps, 
using  the  4100  enhancements,  etc.). 


Please  suggest  topics  you  would  like  to  have  presented  at  future 
workshops:  (CONTINUED) 

-  Data  input  development 

-  Concurrent  and/or  separate  sessions  on  unique  software 
capabilities  (superposition  and/or  single  photo  resection  in 
wang;  maps  capabilities;  expert  systems;  etc.)  user  seminars  on 
specific  techniques  used  for  special  applications;  CIS 
integration  activities  and  development. 


The  Workshop  meeting  facilities  were: 

Good  =  15   Satisfactory  =  9   Unsatisfactory  =  3 

Comments : 

-  The  facilities  were  excellent;   however,  the  cost  was  quite 
high  for  food,  drinks,  phone  calls,  etc.,  with  no  alternative 
establishments  close  by.   It  was  difficult  to  stay  within  per- 
diem  rates. 

-  Too  far  from  federal  center,  and  parking  wasn't  free. 

-  Hotel  costs  exceeded  per  diem  limits.   Poor  location  in  regards 
to  eating  and  other  facilities.   Meeting  room  was  good  except 
for  the  cold  air  conditioning  the  first  two  days. 

-  A  more  diverse  facility,  with  nearby  restaurants, 
entertainment . 

-  Good  facilities;  however,  I  didn't  like  the  location.   This 
is  an  expensive  area  of  town, and  if  you  don't  have  a  car 
you're  stranded. 

-  Expensive  meals,  isolated  location;  friendly  hotel  personnel. 

-  Expensive,  not  centrally  located. 

-  The  rooms  themselves  were  excellent,  but  meeting  rooms  were 
cold  and  there  were  too  few  restaurants,  etc. ,  within  walking 
distance  for  those  with  limited  budgets  or  no  cars. 

-  Tuesday  P.M.  session  was  terrible  because  of  freezing 
air  conditioning. 

-  The  conference  room  was  uncomfortably  cold  the  first  two  days. 

-  Out  of  control  air  conditioning. 

-  Adjacent  meetings,  other  groups  were  noisy. 

Additional  comments  and/or  constructive  suggestions: 

-  Locate  closer  to  DSC  (use  of  DSC  facilities  for  possible 
software  seminars) . 

-  I  would  like  to  see  a  copy  of  the  proceedings  of  the  paper 
presentations  printed  and  available  at  the  beginning  of  the 
workshop  (not  lagging  months  later) . 

-  MOSS  Users  directory:   Names,  addresses,  GIS  responsibility, 
GIS  equipment  used  in  office  (this  could  be  used  as  an  address 
list  for  a  future  MOSS  Users  newsletter) . 


Additional  comments  and/or  constructive  suggestions:  (CONTINUED) 

-  Feedback  on  software  testing. 

-  A  location  with  more  restaurant  alternatives  close  to 
facilities  would  be  nice= 

-  Having  the  conference  at  a  cheaper  motel  and  more  convenient 
restaurant  service  (closer  to  the  downtown  area) . 

-  Request  that  paper  presenters  bring  copies  to  distribute  before 
presentation , 

-  Thanks  and  congratulations  to  BIA  for  a  very  well  managed  and 
well  planned  workshop. 

-  The  airport  location  was  inconvenient,  expensive,  with  no 
eating  establishments  in  the  near  vicinity.   Suggest  CSU  campus 
or  DSC  area  for  future  location. 

-  Hold  next  workshop  in  an  area  with  a  variety  of  restaurants 
within  walking  distance. 

-  Workshop  was  well  organized  and  holding  speakers  to  2  0  minutes 
really  helped  move  the  Workshop  along.   It  might  be  helpful  to 
conduct  surveys  on  management.  Users,  and  Systems  problems 
before  conducting  these  sessions.   This  way,  these  problems  can 
be  addressed  during  these  sessions.   Overall,  this  was  the  best 
workshop  yet. 

-  I'd  like  to  see  the  poster  sessions  returned  to  the  program. 
ERSI  seemed  to  have  had  several  opportunities  to  inject  their 
"thoughts"  on  MOSS  through  both  presentations  and  vendor  help. 
Chairpersons  did  an  excellent  job  of  keeping  presentations  on 
schedule.   Denver  is  a  good  location.   A  more  central  hotel 
would  help  those  without  autos  available. 

-  I  would  sincerely  like  to  receive  additional  information  on 
C.S.U.  and  their  programs  in  GIS  and  other  activities.   C.S.U. 
appears  to  be  very  dynamic  and  taking  a  leadership  role  in  the 
field. 

-  Facilities  closer  to  other  facilities,  such  as  theaters, 
shopping,  tourist  type  attractions,  would  be  very  nice. 

-  Prior  clearing  with  hotel  to  prevent  taxing  room  charges  for 
government  employees. 

-  No  restaurants  near  the  hotel  that  were  reasonable. 

-  I  would  like  to  see  training  courses  for  MOSS  users  as  an 
option. 

-  Locate  future  Workshop  in  an  area  where  more  restaurants/ 
activities  are  available. 

-  Keep  the  facilities  within  the  allowable  per  diem  (tax 
included) .   Better  access  to  restaurants/shops. 

-  Hotel  should  send  out  confirmation  of  lodging  reservation. 

-  This  workshop  appears  to  have  made  considerable  progress  to 
bringing  the  MOSS  family  together,  and  if  true,  will  result  in 
a  very  good  system  in  the  near  future.   Please  follow  through. 

-  Summary  of  s/w  status  at  workshop  start.   Should  be  copies  of 
presentation  papers  available  in  advance  -  a  table  should  be 
set  up  with  display  copies  of  materials  available  on  GIS  from 
other  agencies  and  sign  up  list  for  copies. 
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